12017-03-30T00:06:36 *** alpalp has joined #bitcoin-core-dev
22017-03-30T00:06:36 *** alpalp has joined #bitcoin-core-dev
32017-03-30T00:09:58 *** QBcrusher has quit IRC
42017-03-30T00:11:29 *** dodomojo has joined #bitcoin-core-dev
52017-03-30T00:22:28 *** droark has quit IRC
62017-03-30T00:32:32 *** bityogi has quit IRC
72017-03-30T00:43:42 *** Giszmo has quit IRC
82017-03-30T00:54:08 *** Ylbam has quit IRC
92017-03-30T00:59:38 *** trippysalmon has quit IRC
102017-03-30T01:01:17 *** trippysalmon has joined #bitcoin-core-dev
112017-03-30T01:24:53 *** To7 has joined #bitcoin-core-dev
122017-03-30T01:40:51 *** Apocalyptic has joined #bitcoin-core-dev
132017-03-30T02:22:13 <luke-jr> I wonder if it would be better to prune debug.log with fallocate/FALLOC_FL_PUNCH_HOLE
142017-03-30T02:24:18 *** str4d has quit IRC
152017-03-30T02:24:54 *** Rspigler has joined #bitcoin-core-dev
162017-03-30T02:35:42 *** Rspigler has quit IRC
172017-03-30T02:47:01 *** alpalp has quit IRC
182017-03-30T03:20:25 *** sydc has joined #bitcoin-core-dev
192017-03-30T03:54:54 *** dodomojo has quit IRC
202017-03-30T03:58:38 *** dodomojo has joined #bitcoin-core-dev
212017-03-30T03:58:47 *** justan0theruser has joined #bitcoin-core-dev
222017-03-30T03:59:49 *** justanotheruser has quit IRC
232017-03-30T04:11:18 *** dodomojo has quit IRC
242017-03-30T04:13:19 *** goksinen has joined #bitcoin-core-dev
252017-03-30T04:14:11 *** goksinen has quit IRC
262017-03-30T04:20:44 *** goksinen has joined #bitcoin-core-dev
272017-03-30T04:31:26 *** goksinen has quit IRC
282017-03-30T04:36:58 *** niska has quit IRC
292017-03-30T04:43:13 *** niska has joined #bitcoin-core-dev
302017-03-30T05:01:23 <bitcoin-git> [bitcoin] tjps closed pull request #10059: [trivial] Removed one Boost usage and headers in util.cpp (master...tjps_boost) https://github.com/bitcoin/bitcoin/pull/10059
312017-03-30T05:08:24 *** BlueMatt has quit IRC
322017-03-30T05:08:39 *** BlueMatt has joined #bitcoin-core-dev
332017-03-30T05:11:29 *** squidicuz has quit IRC
342017-03-30T05:11:55 *** squidicuz has joined #bitcoin-core-dev
352017-03-30T05:33:00 *** BlueMatt has quit IRC
362017-03-30T05:37:08 *** BlueMatt has joined #bitcoin-core-dev
372017-03-30T06:06:29 <wumpus> achow101: there's been discussion of having a signal to prune the debug log on command, none exists though. SIGHUP does reopen it, so you could rotate it using a stock log rotator
382017-03-30T06:07:56 <wumpus> with default settings the debug log grows only very slowly so this is not an issue for most users
392017-03-30T06:08:17 <wumpus> and developers that enable extra debug options tend to not want to automatically lose information
402017-03-30T06:08:24 <wumpus> e.g. to collect info over a complete sync cycle
412017-03-30T06:10:26 <gmaxwell> the way the prune thing works kinda stinks in any case. when I get log data from users it very frequently has omitted the interesting part, because they restart before asking for help.
422017-03-30T06:10:37 <gmaxwell> and so I can't see why their node has rejected a valid block.
432017-03-30T06:30:48 *** helo has quit IRC
442017-03-30T06:32:33 *** helo has joined #bitcoin-core-dev
452017-03-30T06:48:37 *** Ylbam has joined #bitcoin-core-dev
462017-03-30T06:56:49 *** BashCo has quit IRC
472017-03-30T06:57:29 *** BashCo has joined #bitcoin-core-dev
482017-03-30T07:02:11 *** BashCo has quit IRC
492017-03-30T07:03:49 *** dcousens has quit IRC
502017-03-30T07:18:30 *** BashCo has joined #bitcoin-core-dev
512017-03-30T07:19:11 <jonasschnelli> BlueMatt: I can't follow your comment: https://github.com/bitcoin/bitcoin/pull/9681/files#r108679775 ... can you elaborate?
522017-03-30T07:23:16 <bitcoin-git> [bitcoin] jtimon opened pull request #10119: Util: Remove ArgsManager wrappers: (master...0.14-args-wrappers) https://github.com/bitcoin/bitcoin/pull/10119
532017-03-30T07:25:23 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f34cdcbd806d...8ac804128671
542017-03-30T07:25:23 <bitcoin-git> bitcoin/master 159fe88 John Newbery: Remove SingleNodeConnCB...
552017-03-30T07:25:24 <bitcoin-git> bitcoin/master 8ac8041 MarcoFalke: Merge #10109: Remove SingleNodeConnCB...
562017-03-30T07:25:47 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10109: Remove SingleNodeConnCB (master...remove_single_node_conn_cb) https://github.com/bitcoin/bitcoin/pull/10109
572017-03-30T07:49:34 *** harrymm has quit IRC
582017-03-30T07:50:47 *** fanquake has joined #bitcoin-core-dev
592017-03-30T07:51:25 <wumpus> FALLOC_FL_PUNCH_HOLE wouldn't improve that; though maybe the aggressive name gives some outlet when there's yet another issue with useless debug logs
602017-03-30T07:52:12 <fanquake> heh https://imgur.com/a/Q5Dsq
612017-03-30T07:53:02 *** vicenteH has joined #bitcoin-core-dev
622017-03-30T07:53:09 <wumpus> fanquake: it's eating blocks instead of syncing them!
632017-03-30T07:54:10 <wumpus> (yes yes '100% progress' is a moving target, so staying in the same place moves you backwards, relatively, you have to run to stay in the same place)
642017-03-30T07:54:35 <wumpus> I guess we should add a max(0, progress)
652017-03-30T07:59:33 *** CubicEarthh has joined #bitcoin-core-dev
662017-03-30T08:00:07 <fanquake> wumpus any schedule for 0.14.1 ? I'm going to remove 9464, not important enough to be fixed.
672017-03-30T08:01:28 <wumpus> fanquake: no precise shedule, though agreement seems to be that there should be a 0.14.1 'soon'
682017-03-30T08:02:15 <fanquake> Only two issues tagged now, are there any more sitting around that should be making it in?
692017-03-30T08:02:22 <wumpus> it's still blocked on the out of memory problems, we're going to PR some workarounds for 0.14
702017-03-30T08:02:41 <wumpus> yep I'm working on one and sipa should have one
712017-03-30T08:02:47 <fanquake> ok
722017-03-30T08:03:33 *** harrymm has joined #bitcoin-core-dev
732017-03-30T08:04:17 <wumpus> agree about #9464, as a display problem it's fairly low priority and should at least not block 0.14.1
742017-03-30T08:04:18 <gribble> https://github.com/bitcoin/bitcoin/issues/9464 | [GUI] No GUI updates when running with --reindex or --reindex-chainstate · Issue #9464 · bitcoin/bitcoin · GitHub
752017-03-30T08:04:29 *** talmai has joined #bitcoin-core-dev
762017-03-30T08:04:32 <wumpus> but if someone fixes it it and the solution is not too invasive should be backported
772017-03-30T08:05:51 <bitcoin-git> [bitcoin] fanquake closed pull request #10089: Fix shadowing of 'what' as described in #10080. (master...fix-what-shadowing) https://github.com/bitcoin/bitcoin/pull/10089
782017-03-30T08:06:50 <wumpus> hrm some RPCs such as getmemoryinfo could be available from the point the RPC server is launched, not just after iniitalization finishes
792017-03-30T08:07:40 <wumpus> also 'stop'
802017-03-30T08:10:34 *** talmai has quit IRC
812017-03-30T08:16:21 <bitcoin-git> [bitcoin] laanwj opened pull request #10120: util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (master...2017_03_address_space_exhaustion_workaround) https://github.com/bitcoin/bitcoin/pull/10120
822017-03-30T08:38:41 *** chjj has joined #bitcoin-core-dev
832017-03-30T08:57:48 *** owowo has quit IRC
842017-03-30T08:58:32 *** chjj has quit IRC
852017-03-30T09:00:42 *** chjj has joined #bitcoin-core-dev
862017-03-30T09:01:49 *** chjj has joined #bitcoin-core-dev
872017-03-30T09:03:50 *** riemann has joined #bitcoin-core-dev
882017-03-30T09:05:46 *** jtimon has quit IRC
892017-03-30T09:06:47 *** CubicEarthh has quit IRC
902017-03-30T09:17:48 *** BashCo_ has joined #bitcoin-core-dev
912017-03-30T09:19:07 *** BashCo has quit IRC
922017-03-30T09:21:59 <luke-jr> wumpus: maybe debug.log should only be pruned when the node considers itself synced + some time has passed?
932017-03-30T09:22:20 <luke-jr> (FALLOC_FL_PUNCH_HOLE possible improvement is that it can do it without rewriting the kept data)
942017-03-30T09:23:15 <jonasschnelli> fanquake: does #9464 fixes the negative progress (https://imgur.com/a/Q5Dsq)?
952017-03-30T09:23:16 <gribble> https://github.com/bitcoin/bitcoin/issues/9464 | [GUI] No GUI updates when running with --reindex or --reindex-chainstate · Issue #9464 · bitcoin/bitcoin · GitHub
962017-03-30T09:24:34 *** herzmeister[m] has quit IRC
972017-03-30T09:24:34 *** frabrunelle has quit IRC
982017-03-30T09:24:34 *** kewde[m] has quit IRC
992017-03-30T09:25:13 <fanquake> jonasschnelli no, 9464 is just an issue I created that cover a few different GUI issues/quirks, I should add the negative progress output there as well.
1002017-03-30T09:25:48 *** paveljanik has quit IRC
1012017-03-30T09:26:24 *** herzmeister[m] has joined #bitcoin-core-dev
1022017-03-30T09:34:41 *** chjj has quit IRC
1032017-03-30T09:35:26 *** chjj has joined #bitcoin-core-dev
1042017-03-30T09:37:26 <wumpus> btw travis is being flaky on master
1052017-03-30T09:37:42 <wumpus> not sure if this is caused by #9294
1062017-03-30T09:37:46 <gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub
1072017-03-30T09:38:14 <jonasschnelli> oh... i'll check
1082017-03-30T09:39:52 <jonasschnelli> assumevalid.py failed...
1092017-03-30T09:39:58 <jonasschnelli> maybe a rebase/merge issue.
1102017-03-30T09:42:37 <wumpus> travis is failing on #10120 as well, but on wallet-hd.py
1112017-03-30T09:42:38 <gribble> https://github.com/bitcoin/bitcoin/issues/10120 | util: Work around (virtual) memory exhaustion on 32-bit w/ glibc by laanwj · Pull Request #10120 · bitcoin/bitcoin · GitHub
1122017-03-30T09:42:42 <wumpus> could also be a test framework related issue
1132017-03-30T09:43:38 <fanquake> jonasschnelli what are your thoughts on the OSX Growl notification code? I'm not sure that it's even being developed/supported anymore. They moved to selling it through the mac app store, and last update was in October 2013.
1142017-03-30T09:44:47 <wumpus> test_framework.authproxy.JSONRPCException: non-JSON HTTP response with '503 Service Unavailable' from server (-342)
1152017-03-30T09:45:06 <wumpus> while waiting for the node to come up... I think you'll get that if no handler is installed
1162017-03-30T09:45:29 <wumpus> there is a small window before handlers are registered
1172017-03-30T09:45:35 <wumpus> so not completely unexpected
1182017-03-30T09:46:16 <fanquake> wumpus did you just restart the build? I was in the middle on reading the log heh
1192017-03-30T09:46:24 *** kewde[m] has joined #bitcoin-core-dev
1202017-03-30T09:46:24 *** frabrunelle has joined #bitcoin-core-dev
1212017-03-30T09:46:28 <wumpus> yes I restarted the build, sorry :)
1222017-03-30T09:52:46 <wumpus> may well be that travis is just being slow and brings this issue to the surface
1232017-03-30T10:10:10 *** To7 has quit IRC
1242017-03-30T11:23:03 *** AaronvanW has joined #bitcoin-core-dev
1252017-03-30T11:23:03 *** AaronvanW has joined #bitcoin-core-dev
1262017-03-30T11:28:07 *** jl2012 has quit IRC
1272017-03-30T11:42:46 <jonasschnelli> wumpus: hmmm.. assumevalid.py failed/failes on master (CRON travis): https://travis-ci.org/bitcoin/bitcoin/jobs/216360061#L5396
1282017-03-30T11:42:50 <jonasschnelli> Can't reproduce locally
1292017-03-30T11:42:59 <jonasschnelli> (I try now on Ubuntu 14.04
1302017-03-30T11:50:41 <wumpus> I couldn't reproduce it locally either
1312017-03-30T12:10:12 *** To7 has joined #bitcoin-core-dev
1322017-03-30T12:18:00 *** alpalp has joined #bitcoin-core-dev
1332017-03-30T12:18:00 *** alpalp has joined #bitcoin-core-dev
1342017-03-30T12:21:58 *** makriath has joined #bitcoin-core-dev
1352017-03-30T12:27:29 *** makriath has quit IRC
1362017-03-30T12:30:58 <jnewbery> #10114 should fix assumevalid.py (and make assumptions in test cases more robust in general)
1372017-03-30T12:30:59 <gribble> https://github.com/bitcoin/bitcoin/issues/10114 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
1382017-03-30T12:31:18 <wumpus> jnewbery: great!
1392017-03-30T12:31:59 <jnewbery> Travis is good (too good!) at uncovering sync and timing issues
1402017-03-30T12:32:09 <wumpus> yes
1412017-03-30T12:37:25 *** AaronvanW has quit IRC
1422017-03-30T12:40:24 *** jl2012 has joined #bitcoin-core-dev
1432017-03-30T12:43:25 *** alpalp has quit IRC
1442017-03-30T13:00:29 *** alpalp has joined #bitcoin-core-dev
1452017-03-30T13:00:29 *** alpalp has joined #bitcoin-core-dev
1462017-03-30T13:06:10 *** alpalp has quit IRC
1472017-03-30T13:14:01 *** bityogi has joined #bitcoin-core-dev
1482017-03-30T13:20:06 *** riemann has quit IRC
1492017-03-30T13:22:34 *** kexkey has joined #bitcoin-core-dev
1502017-03-30T13:25:42 *** Guyver2 has joined #bitcoin-core-dev
1512017-03-30T13:29:05 *** fanquake has quit IRC
1522017-03-30T13:29:30 <BlueMatt> jonasschnelli: ie the user might call bumpfee, get an error saying they need to pay more, then call bumpfee again with a higher number, and get another error saying they need to pay /even/ more
1532017-03-30T13:29:35 <BlueMatt> which is ok, but kinda annoying
1542017-03-30T13:29:47 <BlueMatt> if they're already checked back-to-back, might as well merge them into one error
1552017-03-30T13:29:51 <BlueMatt> so that that cant happen
1562017-03-30T13:42:57 *** kexkey has quit IRC
1572017-03-30T13:52:14 *** harrymm has quit IRC
1582017-03-30T13:53:17 <bitcoin-git> [bitcoin] shitakee opened pull request #10121: Add missing header file (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10121
1592017-03-30T13:56:56 *** paveljanik has joined #bitcoin-core-dev
1602017-03-30T13:56:56 *** paveljanik has joined #bitcoin-core-dev
1612017-03-30T14:04:46 *** owowo has joined #bitcoin-core-dev
1622017-03-30T14:10:55 *** harrymm has joined #bitcoin-core-dev
1632017-03-30T14:21:02 *** Giszmo has joined #bitcoin-core-dev
1642017-03-30T14:27:57 *** compumatrix has joined #bitcoin-core-dev
1652017-03-30T14:32:15 <compumatrix> Is it really this silent in here?
1662017-03-30T14:36:41 *** magicwund has joined #bitcoin-core-dev
1672017-03-30T14:37:00 <compumatrix> hi magicwund...
1682017-03-30T14:38:01 *** d9b4bef9 has quit IRC
1692017-03-30T14:38:03 <magicwund> hey
1702017-03-30T14:39:08 *** d9b4bef9 has joined #bitcoin-core-dev
1712017-03-30T14:39:15 *** AaronvanW has joined #bitcoin-core-dev
1722017-03-30T14:54:05 *** schnerchi has left #bitcoin-core-dev
1732017-03-30T14:54:18 *** talmai has joined #bitcoin-core-dev
1742017-03-30T14:54:29 *** schnerchi has joined #bitcoin-core-dev
1752017-03-30T15:17:14 *** thermoman has joined #bitcoin-core-dev
1762017-03-30T15:17:53 *** talmai has quit IRC
1772017-03-30T15:27:00 *** compumatrix has quit IRC
1782017-03-30T15:32:57 <bitcoin-git> [bitcoin] jnewbery opened pull request #10123: Allow debug logs to be excluded from specified component (master...debugexclude) https://github.com/bitcoin/bitcoin/pull/10123
1792017-03-30T15:37:21 *** magicwund has quit IRC
1802017-03-30T15:43:09 *** abpa has joined #bitcoin-core-dev
1812017-03-30T15:45:56 *** magicwund has joined #bitcoin-core-dev
1822017-03-30T16:02:43 <bitcoin-git> [bitcoin] jnewbery opened pull request #10124: [test] Suppress test logging spam (master...suppress_test_logging_spam) https://github.com/bitcoin/bitcoin/pull/10124
1832017-03-30T16:11:39 *** BashCo_ has quit IRC
1842017-03-30T16:12:13 *** BashCo has joined #bitcoin-core-dev
1852017-03-30T16:16:35 *** BashCo has quit IRC
1862017-03-30T16:19:46 *** Guyver2_ has joined #bitcoin-core-dev
1872017-03-30T16:22:48 *** Guyver2 has quit IRC
1882017-03-30T16:22:57 *** Guyver2_ is now known as Guyver2
1892017-03-30T16:31:17 *** jtimon has joined #bitcoin-core-dev
1902017-03-30T16:35:20 *** BashCo has joined #bitcoin-core-dev
1912017-03-30T16:51:00 <jonasschnelli> Reminder for the european CEST people. Meeting will be in 2h 10' (summer time now!).
1922017-03-30T17:20:27 <kanzure> i thought we had consensus to eliminate time zones?
1932017-03-30T17:21:08 <gmaxwell> kanzure: we did, but the rest of the world hasn't yet.
1942017-03-30T17:41:40 *** afk11 has joined #bitcoin-core-dev
1952017-03-30T17:43:52 *** JackH has quit IRC
1962017-03-30T17:44:17 *** rcd has joined #bitcoin-core-dev
1972017-03-30T17:48:10 *** CubicEarthh has joined #bitcoin-core-dev
1982017-03-30T17:54:41 *** brg444_ has joined #bitcoin-core-dev
1992017-03-30T17:54:42 *** wbnns_ has joined #bitcoin-core-dev
2002017-03-30T17:54:46 *** mappum_ has joined #bitcoin-core-dev
2012017-03-30T17:59:34 *** wbnns has quit IRC
2022017-03-30T17:59:34 *** brg444 has quit IRC
2032017-03-30T17:59:34 *** jonasschnelli has quit IRC
2042017-03-30T17:59:35 *** mappum has quit IRC
2052017-03-30T17:59:36 *** Soligor has quit IRC
2062017-03-30T17:59:43 *** wbnns_ is now known as wbnns
2072017-03-30T17:59:53 *** jonasschnelli has joined #bitcoin-core-dev
2082017-03-30T18:00:03 *** brg444_ is now known as brg444
2092017-03-30T18:00:58 *** Soligor has joined #bitcoin-core-dev
2102017-03-30T18:01:38 *** mappum_ is now known as mappum
2112017-03-30T18:05:53 <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10125: Exit bitcoind immediately on shutdown instead of 200ms later (master...2017-03-faster-shutdown) https://github.com/bitcoin/bitcoin/pull/10125
2122017-03-30T18:12:23 *** jonasschnelli has quit IRC
2132017-03-30T18:12:23 *** jonasschnelli has joined #bitcoin-core-dev
2142017-03-30T18:34:34 <bitcoin-git> [bitcoin] jnewbery closed pull request #9630: Add logging to GetAncestor if pindex->pprev == NULL (master...crashlogging) https://github.com/bitcoin/bitcoin/pull/9630
2152017-03-30T18:40:34 <sdaftuar> wumpus: i think #9959 is ready for merge
2162017-03-30T18:40:36 <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
2172017-03-30T18:43:36 *** bsm117532 has quit IRC
2182017-03-30T18:48:34 <wumpus> sdaftuar: ok!
2192017-03-30T18:56:05 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/8ac804128671...cde9b1a864c1
2202017-03-30T18:56:06 <bitcoin-git> bitcoin/master eed816a Suhas Daftuar: Mining: return early when block is almost full
2212017-03-30T18:56:06 <bitcoin-git> bitcoin/master 42cd8c8 Suhas Daftuar: Add benchmarking for CreateNewBlock
2222017-03-30T18:56:07 <bitcoin-git> bitcoin/master 011124a Suhas Daftuar: Update benchmarking with package statistics
2232017-03-30T18:56:30 <bitcoin-git> [bitcoin] laanwj closed pull request #9959: Mining: Prevent slowdown in CreateNewBlock on large mempools (master...2017-03-cnb-optimizations) https://github.com/bitcoin/bitcoin/pull/9959
2242017-03-30T18:57:19 <sdaftuar> thanks!
2252017-03-30T18:57:48 <BlueMatt> wumpus: what restictions are there on what code you can call from signal handlers?
2262017-03-30T18:58:26 <sipa> BlueMatt: as far as I know, only modify simple variables
2272017-03-30T18:58:35 <wumpus> BlueMatt: almost nothing can be invoked from signal handlers because signals arrive synchronously, so can be called in any context from any thread
2282017-03-30T18:59:00 <BlueMatt> mmm
2292017-03-30T18:59:03 <wumpus> everything that has the slightest risk of crashing when called reentrantly can't be used
2302017-03-30T18:59:13 <wumpus> so yes, in practice most programs restrict to setting variables
2312017-03-30T18:59:14 <BlueMatt> hmm, alright
2322017-03-30T18:59:22 <wumpus> another used technique is a pipe
2332017-03-30T19:00:27 <jonasschnelli> *dong*
2342017-03-30T19:00:28 <gmaxwell> sdaftuar: plz backport #9959
2352017-03-30T19:00:29 <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
2362017-03-30T19:00:32 <gmaxwell> #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
2372017-03-30T19:00:39 <kanzure> hi.
2382017-03-30T19:00:45 <sdaftuar> gmaxwell: will do (and here!)
2392017-03-30T19:00:45 <paveljanik> Hi!
2402017-03-30T19:00:48 <wumpus> *reading* from a pipe that has one byte in it, or something like that
2412017-03-30T19:00:59 <michagogo> Oh, right, these are back to 10 PM now that DST is back
2422017-03-30T19:01:00 <jtimon> hi
2432017-03-30T19:01:00 <BlueMatt> wumpus: yea, I get it, but man that sucks
2442017-03-30T19:01:05 <cfields> hi
2452017-03-30T19:01:10 <wumpus> yes, UNIX signals suck
2462017-03-30T19:01:14 <wumpus> #meetingstart
2472017-03-30T19:01:18 <wumpus> #startmeeting
2482017-03-30T19:01:18 <lightningbot> Meeting started Thu Mar 30 19:01:18 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2492017-03-30T19:01:18 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2502017-03-30T19:01:41 <instagibbs> hi
2512017-03-30T19:01:46 <jeremyrubin> here
2522017-03-30T19:01:56 <wumpus> BlueMatt: it shouldn't matter for the AbortNode() case though. Just make the conditional wait 200 milliseconds or so
2532017-03-30T19:02:03 <jtimon> topics?
2542017-03-30T19:02:24 <wumpus> doesn't matter if signals are slightly delayed
2552017-03-30T19:02:30 <BlueMatt> wumpus: the wait is already 200ms
2562017-03-30T19:02:30 <wumpus> yes, topics?
2572017-03-30T19:02:34 <BlueMatt> talk about abortnode
2582017-03-30T19:02:36 <BlueMatt> thats a reasonable topic
2592017-03-30T19:02:38 <wumpus> BlueMatt: yes, but make it a wait on a conditional
2602017-03-30T19:02:44 <BlueMatt> mmm, fair
2612017-03-30T19:02:56 <BlueMatt> yes, for sigterm its reasonable to wait a few 100 ms
2622017-03-30T19:03:03 <BlueMatt> for AbortNode it'll wake it immediately
2632017-03-30T19:03:06 <wumpus> right.
2642017-03-30T19:04:15 <BlueMatt> in other news, so we got 1/6 "Review Priority" PRs merged this week, that's ok, but we can do better :)
2652017-03-30T19:04:45 <BlueMatt> oh, nvm, got 2/6
2662017-03-30T19:04:49 <wumpus> FYI: https://github.com/bitcoin/bitcoin/projects/8
2672017-03-30T19:05:26 <gmaxwell> BlueMatt: 2/6.
2682017-03-30T19:05:28 <wumpus> removed the two that have been merged
2692017-03-30T19:05:28 <jtimon> I don't think anyone commented in mine, at least I got review in others
2702017-03-30T19:05:49 <gmaxwell> I forgot about the project tracker thing, but reviewed some of them anyways.
2712017-03-30T19:06:32 <wumpus> doesn't matter, we'll only add pulls that were mentioned to have priority in the meeting to that project tracker, so if you pay attention at the meeting you don't need it :)
2722017-03-30T19:07:31 <wumpus> anyhow, everyone go review them
2732017-03-30T19:08:00 *** laurentmt has joined #bitcoin-core-dev
2742017-03-30T19:08:21 <wumpus> topic: 0.14.1?
2752017-03-30T19:08:29 <bitcoin-git> [bitcoin] sipa opened pull request #10126: Compensate for memory peak at flush time (master...peak_compensation) https://github.com/bitcoin/bitcoin/pull/10126
2762017-03-30T19:08:29 <gmaxwell> Yes, please.
2772017-03-30T19:08:33 <jeremyrubin> topic: slow tests?
2782017-03-30T19:08:37 <wumpus> #topic 0.14.1
2792017-03-30T19:09:02 <achow101> already?
2802017-03-30T19:09:25 <gmaxwell> yes. lots of nice fixes to ship. Minor releases are minor.
2812017-03-30T19:09:39 <sipa> we have 11 merged PRs marked 0.14.1
2822017-03-30T19:09:59 <wumpus> and three open pulls https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14.1
2832017-03-30T19:10:32 <wumpus> sipa: only one still has the "needs backport" tag, I think MarcoFalke ported the rest
2842017-03-30T19:10:44 <gmaxwell> I think when we get those three in and those and the recent ones backported, we should be goof for a 0.14.1.
2852017-03-30T19:11:11 <gmaxwell> good too.
2862017-03-30T19:11:41 <wumpus> agreed
2872017-03-30T19:12:45 <wumpus> ok, next topic I guess
2882017-03-30T19:12:48 <wumpus> #topic slow tests
2892017-03-30T19:13:11 <wumpus> I made an overview here: https://github.com/bitcoin/bitcoin/issues/10026 of the slowest unit tests
2902017-03-30T19:13:15 <jeremyrubin> A lot of it is my fault it seems. https://github.com/bitcoin/bitcoin/pull/10099 is ready to go
2912017-03-30T19:13:27 <wumpus> some of those have already been worked on or even PRs open to make them faster
2922017-03-30T19:13:36 <gmaxwell> jnewbery: if you're around, if 10106 doesn't move forward in a few hours, I recommend you create a new pr, cherry picking that one fix, with your new tests and the fix for the other function. (just because the PR wasn't opened by a regular so they may not be responsive or may not know how to use github well enough to pull your changes.)
2932017-03-30T19:14:12 <jnewbery> gmaxwell: I'll do that this afternoon
2942017-03-30T19:14:22 *** MarcoFalke_lab has joined #bitcoin-core-dev
2952017-03-30T19:14:43 <wumpus> yes, tend to agree, they may not know how to cherry-pick them. I could cherry-pick them into his branch but meh
2962017-03-30T19:14:53 <MarcoFalke_lab> wumpus: Yes, dropping GetRand() gave a 4* speedup.
2972017-03-30T19:15:02 <gmaxwell> jnewbery: and thanks for the awesome response.
2982017-03-30T19:15:08 <jnewbery> np
2992017-03-30T19:15:37 <wumpus> MarcoFalke_lab: that'll at least move it down a bit in the top 20
3002017-03-30T19:15:42 <jeremyrubin> The cuckoocache tests require a bit more discussion to decrease the parameters; I can pick something arbitrary
3012017-03-30T19:16:27 <jeremyrubin> The checkqueue tests should also speed up a lot with #9938, but I'm preparing some tweaks to those
3022017-03-30T19:16:28 <gribble> https://github.com/bitcoin/bitcoin/issues/9938 | Lock-Free CheckQueue by JeremyRubin · Pull Request #9938 · bitcoin/bitcoin · GitHub
3032017-03-30T19:16:46 <Chris_Stewart_5> re tests: Has anyone given any thought to #8469 , obviously this pull request sacrafices speed for exhaustiveness
3042017-03-30T19:16:48 <gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
3052017-03-30T19:17:02 <jeremyrubin> If anyone has high-core machines, they should try benching how that works
3062017-03-30T19:17:02 <wumpus> jeremyrubin: alternatively we could have an -extended mode for the unit tests, like we have for the functional tests, to do extra-thorough tests that shouldn't run every time
3072017-03-30T19:17:13 <MarcoFalke_lab> jeremyrubin: If the parameters matter, you could provide a switch to test against quick_run and an expensive one
3082017-03-30T19:17:20 <wumpus> yes ^^
3092017-03-30T19:17:27 <gmaxwell> I think we should have an extended test, and make running it part of the release process.
3102017-03-30T19:17:42 <jeremyrubin> Agree
3112017-03-30T19:17:45 <wumpus> but for the standard 'make check' there should be a guideline of max ~1 second per test case
3122017-03-30T19:17:59 <MarcoFalke_lab> Everyone agrees! :)
3132017-03-30T19:18:07 <gmaxwell> I don't care if the tests take an hour to run if it's only a mandatory once in release thing.
3142017-03-30T19:18:09 <cfields> sgtm
3152017-03-30T19:18:11 <jeremyrubin> no, 2 seconds!
3162017-03-30T19:18:18 <wumpus> gmaxwell: yes or once per day or so on master
3172017-03-30T19:18:35 <jonasschnelli> (which is failing currently)
3182017-03-30T19:18:49 <gmaxwell> jonasschnelli: what is failing?
3192017-03-30T19:18:49 <wumpus> yes, travis is broken again, but there's a pull to fix that
3202017-03-30T19:18:52 <cfields> note to self: gitian should run whatever extended tests it can
3212017-03-30T19:18:55 <gmaxwell> oh travis
3222017-03-30T19:18:58 <jonasschnelli> gmaxwell: https://travis-ci.org/bitcoin/bitcoin/builds
3232017-03-30T19:19:13 <MarcoFalke_lab> Jup, will merge the travis fix tonight when I have access to my keys. (If no one beats me to it)
3242017-03-30T19:19:31 <wumpus> does anyone have the # perhaps?
3252017-03-30T19:19:58 <sdaftuar> i think #10114?
3262017-03-30T19:19:59 <MarcoFalke_lab> Though, we should be cautious with putting too much into the cron jobs. The extended test rely on the cache being up to date
3272017-03-30T19:19:59 <gribble> https://github.com/bitcoin/bitcoin/issues/10114 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
3282017-03-30T19:20:10 <MarcoFalke_lab> Otherwise they would break the 49 minute limit on traivs
3292017-03-30T19:20:11 <wumpus> there's also #10072
3302017-03-30T19:20:12 <gribble> https://github.com/bitcoin/bitcoin/issues/10072 | Remove sources of unreliablility in extended functional tests by jnewbery · Pull Request #10072 · bitcoin/bitcoin · GitHub
3312017-03-30T19:20:39 <wumpus> but yes 114 was the one I meant
3322017-03-30T19:20:40 <gmaxwell> We should probably contemplate having some seperate process against master that does continual gitian builds or something.
3332017-03-30T19:21:10 <MarcoFalke_lab> jonasschnelli: Is doing that, gmaxwell
3342017-03-30T19:21:22 <gmaxwell> oh good.
3352017-03-30T19:21:25 <gmaxwell> ignore me.
3362017-03-30T19:21:29 <jonasschnelli> gmaxwell: https://bitcoin.jonasschnelli.ch
3372017-03-30T19:21:32 <wumpus> yes, jonasschnelli has a build server with a very nice web UI
3382017-03-30T19:21:43 <MarcoFalke_lab> jonasschnelli: Are you running the tests?
3392017-03-30T19:21:44 <jonasschnelli> (it's currently by manual trigger)
3402017-03-30T19:21:50 <jonasschnelli> no.. just gitian
3412017-03-30T19:21:55 <gmaxwell> somehow I missed this. cool.
3422017-03-30T19:22:08 <wumpus> travis already runs the tests, this is to get executables for testing
3432017-03-30T19:23:31 <jnewbery> travis is only broken now because we've set it to run the extended tests once per day, so we're currently flushing out all the extended tests that have always failed on travis. I think once #10114 and #10072 are merged the daily runs should succeed reliably
3442017-03-30T19:23:32 <gribble> https://github.com/bitcoin/bitcoin/issues/10114 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
3452017-03-30T19:23:33 <gribble> https://github.com/bitcoin/bitcoin/issues/10072 | Remove sources of unreliablility in extended functional tests by jnewbery · Pull Request #10072 · bitcoin/bitcoin · GitHub
3462017-03-30T19:24:08 <jonasschnelli> thanks jnewbery for the info (and the fixes)
3472017-03-30T19:24:10 *** PaulCapestany has quit IRC
3482017-03-30T19:25:56 <bitcoin-git> [bitcoin] sdaftuar opened pull request #10127: [0.14 backport] Mining: Prevent slowdown in CreateNewBlock on large mempools (0.14...2017-03-backport-cnb-optimizations) https://github.com/bitcoin/bitcoin/pull/10127
3492017-03-30T19:26:48 <wumpus> ok, any other topics?
3502017-03-30T19:27:41 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cde9b1a864c1...edc62c959ab3
3512017-03-30T19:27:42 <bitcoin-git> bitcoin/master 6426716 John Newbery: Add send_await_disconnect() method to p2p-compactblocks.py...
3522017-03-30T19:27:42 <bitcoin-git> bitcoin/master 6a18bb9 John Newbery: [tests] sync_with_ping should assert that ping hasn't timed out...
3532017-03-30T19:27:43 <bitcoin-git> bitcoin/master edc62c9 Wladimir J. van der Laan: Merge #10114: [tests] sync_with_ping should assert that ping hasn't timed out...
3542017-03-30T19:27:49 <gmaxwell> I should make notes for topics...
3552017-03-30T19:27:57 <BlueMatt> oh, new prs
3562017-03-30T19:28:02 <BlueMatt> for review priority
3572017-03-30T19:28:12 <BlueMatt> looks like jonasschnelli already added his
3582017-03-30T19:28:16 <bitcoin-git> [bitcoin] laanwj closed pull request #10114: [tests] sync_with_ping should assert that ping hasn't timed out (master...improve_sync_with_ping) https://github.com/bitcoin/bitcoin/pull/10114
3592017-03-30T19:28:21 <BlueMatt> anyone else have something to add (aside from 0.14.1-tagged things)
3602017-03-30T19:28:22 <wumpus> fine with me, but don't forget the current bunch :p
3612017-03-30T19:28:32 <wumpus> yes please review 0.14.1 tagged things
3622017-03-30T19:28:35 <wumpus> although those should be easy
3632017-03-30T19:28:36 <jonasschnelli> BlueMatt: Yes. The bumpfee refactor (to get a QT fee bump function)
3642017-03-30T19:28:53 <sipa> 0.14.1 has priority, but i'd like to see #9792 in at some point to further the get-rid-of-openssl thing :)
3652017-03-30T19:29:01 <BlueMatt> wumpus: there is a "For backport" column there...
3662017-03-30T19:29:02 <gribble> https://github.com/bitcoin/bitcoin/issues/9792 | FastRandomContext improvements and switch to ChaCha20 by sipa · Pull Request #9792 · bitcoin/bitcoin · GitHub
3672017-03-30T19:29:08 <wumpus> but I think we should be able to do 0.14.1 tomorrow so to have something to review for the rest of the week :D
3682017-03-30T19:29:22 <wumpus> BlueMatt: yes good point
3692017-03-30T19:29:53 <BlueMatt> ok, so morcos and sdaftuar get to propose new ones since they dont have ones up, anyone else want to propose ones?
3702017-03-30T19:29:55 <gmaxwell> oh someone opened a PR to do something with debug log excludes, and it adds more insane string processing in the debugging critical path. Would anyone mind if I brought back the PR I shelved to make debug categories use an enum?
3712017-03-30T19:30:17 <BlueMatt> gmaxwell: wfm, the pr was jnewbery's
3722017-03-30T19:30:20 <sipa> gmaxwell: ack enum debug categories
3732017-03-30T19:30:40 <wumpus> gmaxwell: not sure
3742017-03-30T19:30:43 <jnewbery> #10123
3752017-03-30T19:30:44 <gribble> https://github.com/bitcoin/bitcoin/issues/10123 | Allow debug logs to be excluded from specified component by jnewbery · Pull Request #10123 · bitcoin/bitcoin · GitHub
3762017-03-30T19:30:48 <gmaxwell> (the PR was just shelved because I opened it right before a release, and it is a conflict-the-universe PR)
3772017-03-30T19:30:57 *** JackH has joined #bitcoin-core-dev
3782017-03-30T19:30:59 <wumpus> gmaxwell: well no I guess it makes sense
3792017-03-30T19:31:00 <BlueMatt> gmaxwell: go for it now, I'd say
3802017-03-30T19:31:05 <wumpus> yes, do it
3812017-03-30T19:31:07 <sdaftuar> i'd like to get this DisconnectTip improvement wrapped up (#9208) but i need some help on resolving this annoying issue BlueMatt raised
3822017-03-30T19:31:08 <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
3832017-03-30T19:31:08 <cfields> gmaxwell: +1.
3842017-03-30T19:31:14 <jonasschnelli> Yes. ACK
3852017-03-30T19:31:23 <cfields> along the same lines, I'd like to do something similar for net messages
3862017-03-30T19:31:23 <wumpus> then you can also map the enum values to strings and automate the help message generation
3872017-03-30T19:31:26 <gmaxwell> #9424
3882017-03-30T19:31:27 <gribble> https://github.com/bitcoin/bitcoin/issues/9424 | Change LogAcceptCategory to use uint32_t rather than sets of strings. by gmaxwell · Pull Request #9424 · bitcoin/bitcoin · GitHub
3892017-03-30T19:31:30 <BlueMatt> sdaftuar: want to bring it up now/
3902017-03-30T19:31:38 <jnewbery> gmaxwell: +1. I'll happily review that one
3912017-03-30T19:31:38 <BlueMatt> ?
3922017-03-30T19:31:48 <wumpus> cfields: yes, should be fairly easy to do, I already changed the syntax for net messages to be enum-like at some point
3932017-03-30T19:31:49 <jtimon> since #8855 didn't got new review nor re-review I think just leave that (just remind to potential reviewers that #8994 continues it, in case you "don't see the point")
3942017-03-30T19:31:51 <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
3952017-03-30T19:31:51 <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
3962017-03-30T19:32:15 <wumpus> cfields: went as far as I could without making it an actual enum :)
3972017-03-30T19:32:17 <gmaxwell> cfields: I looked at adding a perfect hash for net messages... but didn't know if that would be a way you'd want to go. :)
3982017-03-30T19:32:29 <BlueMatt> new for review this week is 9792 and 9208
3992017-03-30T19:32:35 <cfields> wumpus: yes, it sure looks like an enum :)
4002017-03-30T19:32:37 <sipa> gmaxwell: just make sure all debug category names have different length
4012017-03-30T19:33:12 <gmaxwell> sipa: well we don't need to do any runtime lookup of category names at all.. so no need to do anything performant there.
4022017-03-30T19:33:27 <wumpus> at least give them consecutive values so a bit field can be used to represent the set
4032017-03-30T19:33:33 <wumpus> intead of a per-thread map :-(
4042017-03-30T19:33:40 <cfields> gmaxwell: i had considered making it an array<char, 12>. But I really don't care, as long as it's switchable and a compile-time constant
4052017-03-30T19:33:41 <gmaxwell> wumpus: that is what PR 9424 does.
4062017-03-30T19:33:52 <wumpus> gmaxwell: ok, great
4072017-03-30T19:33:53 <gmaxwell> wumpus: it assigns them each to a bit.
4082017-03-30T19:34:22 <wumpus> the current code that assigns it a thread-local variable is really strange
4092017-03-30T19:34:27 *** PaulCapestany has joined #bitcoin-core-dev
4102017-03-30T19:34:27 <bitcoin-git> [bitcoin] JeremyRubin opened pull request #10128: Speed Up CuckooCache tests (master...cuckoo-tests-faster) https://github.com/bitcoin/bitcoin/pull/10128
4112017-03-30T19:34:30 <cfields> (and now that I think about it, std::array probably isn't switchable anyway)
4122017-03-30T19:34:39 <gmaxwell> yes. horrors from beyond time.
4132017-03-30T19:34:54 <sdaftuar> topic suggestion: dealing with abortnode / ConnectTip / DisconnectTip failures
4142017-03-30T19:35:05 <gmaxwell> in any case, if people support-- 9424 is hard to rebase because it touches the whole codebase.
4152017-03-30T19:35:30 <wumpus> cfields: in some modern languages it's possible to switch on compound types and arrays and strings, but no, not c++XX before XX=50 or so :)
4162017-03-30T19:35:33 <gmaxwell> but I think it also makes jnewbery's exclude trivial. (in fact: no runtime impact...)
4172017-03-30T19:35:50 <wumpus> gmaxwell: yes, it's how it should be done
4182017-03-30T19:36:09 <sipa> in haskell it's pretty much the only way you can inspect a compound type at all :p
4192017-03-30T19:36:14 <jnewbery> gmaxwell: agree
4202017-03-30T19:36:22 <wumpus> sipa: indeed
4212017-03-30T19:36:41 <sipa> ok, sdaftuar's topic?
4222017-03-30T19:36:46 <gmaxwell> cfields: my intution for that would be using gperf to map the messages to integers. then switching on them... but perhaps overkill.
4232017-03-30T19:36:53 <wumpus> #topic dealing with abortnode / ConnectTip / DisconnectTip failures
4242017-03-30T19:37:05 <BlueMatt> context: #9208
4252017-03-30T19:37:06 <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
4262017-03-30T19:37:09 <sipa> sdaftuar: i saw i was pinged in the PR, but haven't read it
4272017-03-30T19:37:13 <sdaftuar> so this issue might be hard to grasp without reviewing #9208
4282017-03-30T19:37:15 <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
4292017-03-30T19:37:29 <wumpus> gmaxwell: will that work for unknown messages too?
4302017-03-30T19:37:40 <sdaftuar> but basically matt brought up that we have some edge cases in our code if ConnectTip or DisconnectTip return false
4312017-03-30T19:37:54 <wumpus> gmaxwell: does a perfect hash handle collisions? I don't remember
4322017-03-30T19:38:07 <cfields> wumpus: perfect hash means no collisions :)
4332017-03-30T19:38:13 <wumpus> cfields: for known values
4342017-03-30T19:38:34 <jeremyrubin> wouldn't that not be backwards compatible?
4352017-03-30T19:38:36 <gmaxwell> wumpus: gperf can check, it's an option.
4362017-03-30T19:38:44 <wumpus> cfields: but what if 'moo' maps to the same 32-bit value as 'block'
4372017-03-30T19:38:50 <jeremyrubin> someone sends you a new type of message that hashes to something else
4382017-03-30T19:39:05 <wumpus> scary
4392017-03-30T19:39:06 <sipa> sdaftuar: hmm, i'll review the PR
4402017-03-30T19:39:10 <sdaftuar> the last issue i'm trying to resolve is if ConnectTip fails (but the block is not invalid), then we should be in an AbortNode() state. what consistency are we aiming for in this situation?
4412017-03-30T19:39:14 <cfields> wumpus: ah, true
4422017-03-30T19:39:16 <gmaxwell> wumpus: making it never have collisions for unknows is just an extra comparison with the correct value.
4432017-03-30T19:39:35 <gmaxwell> wumpus: which IIRC the gperf emitted code will do, if enabled.
4442017-03-30T19:39:47 <gmaxwell> (actually, looks like it's the default)
4452017-03-30T19:39:47 <BlueMatt> lol, ok, so lets pick a topic instead of two
4462017-03-30T19:39:55 *** PaulCapestany has quit IRC
4472017-03-30T19:40:16 <gmaxwell> sdaftuar: we should be able to shut down and come back up with the underlying issue resolved and continue.
4482017-03-30T19:40:26 <wumpus> yes, sorry, I was just curous about gperf
4492017-03-30T19:40:30 <gmaxwell> sdaftuar: I don't care if we lose a bunch of recent blocks.
4502017-03-30T19:40:32 <sipa> sdaftuar: it's fine if we lose progress in that case, but if at all avoidable, the on disk state should not be corrupted
4512017-03-30T19:40:44 <BlueMatt> anyway, so I further observed that shutdown upon AbortNode can take up to 200ms (see recent PR), which is somewhat frightening, given that mempool and chainstate may not be consistent which we assume in many places :/
4522017-03-30T19:40:46 <sdaftuar> gmaxwell: sipa: what should we do with the mempool?
4532017-03-30T19:41:03 <sipa> sdaftuar: who cares?
4542017-03-30T19:41:08 <BlueMatt> so we keep running for a while normally and possibly have incorrect assumptions
4552017-03-30T19:41:11 <gmaxwell> I don't care.
4562017-03-30T19:41:16 <wumpus> just drop it
4572017-03-30T19:41:29 <sipa> sdaftuar: at restart we'll try to reimport what is on disk
4582017-03-30T19:41:36 <sipa> and re-run all necessary consistency checks
4592017-03-30T19:41:51 <sipa> so mempool.dat doesn't need to be consistent with the chainstate
4602017-03-30T19:41:59 <BlueMatt> and wallet?
4612017-03-30T19:42:01 <sdaftuar> i think the concern matt was raising was if before shutdown, it's possible for eg an RPC call to get incorrect results
4622017-03-30T19:42:04 <sdaftuar> or the wallet
4632017-03-30T19:42:08 <wumpus> yes, no tight coupling, good design
4642017-03-30T19:42:19 <BlueMatt> wumpus: point is we *have* tight coupling
4652017-03-30T19:42:22 <wumpus> wallet doesn't need to be in sync either, though it should not be ahead
4662017-03-30T19:42:24 <sipa> sdaftuar: ugh
4672017-03-30T19:42:28 <BlueMatt> and continue running after realizing something is corrupted
4682017-03-30T19:42:35 <gmaxwell> well abortnode should be instant-ish.
4692017-03-30T19:42:36 *** molz_ has joined #bitcoin-core-dev
4702017-03-30T19:42:42 <gmaxwell> BlueMatt: so you're fixing that, what is there to discuss?
4712017-03-30T19:42:46 <wumpus> a bit behind (as long as it's not further than the prune distance) is ok, it will catch up in next start
4722017-03-30T19:42:49 <BlueMatt> gmaxwell: i mean the new pr is an improvement, but its not a fix
4732017-03-30T19:43:02 <BlueMatt> its not like you cant have something pending cs_main when coming out of Disconnect/ConnectTip
4742017-03-30T19:43:06 <wumpus> but if the wallet is ahead of the chain it will trigger a rescan IIRC
4752017-03-30T19:43:10 <gmaxwell> so perhaps abortnode needs to Abort()?
4762017-03-30T19:43:18 <BlueMatt> gmaxwell: thats pretty much the question
4772017-03-30T19:43:21 <BlueMatt> thats super shit, though, of course
4782017-03-30T19:43:24 <gmaxwell> and not faffabout witht politely shutting off threads.
4792017-03-30T19:43:24 <wumpus> I don't think so
4802017-03-30T19:43:39 <sdaftuar> i inadvertently introduced an assert failure in one of these situations. maybe that's a feature not a flaw! :)
4812017-03-30T19:43:44 <gmaxwell> Why is it shit? we should be durable across a power off, which is worse than aborting.
4822017-03-30T19:43:45 <wumpus> the point of abortnode is to be able to show a GUI dialog to the user
4832017-03-30T19:43:55 <gmaxwell> ah
4842017-03-30T19:43:57 <wumpus> if you abort() the user will never know to check the debug.log
4852017-03-30T19:44:07 <BlueMatt> wumpus: well we can show a gui dialog and abort() prior to unlocking cs_main
4862017-03-30T19:44:09 <BlueMatt> :P
4872017-03-30T19:44:15 <jeremyrubin> have a graceful shutdown falg
4882017-03-30T19:44:19 <jeremyrubin> *flag
4892017-03-30T19:44:24 <gmaxwell> wumpus: but it's not unlikely that we can't show a gui... if we can't allocate (likely cause).
4902017-03-30T19:44:27 <BlueMatt> which would effectively be sufficient
4912017-03-30T19:44:29 <wumpus> I always thought that AbortNode was for errors that could tolerate a graceful shutdown
4922017-03-30T19:44:35 <wumpus> the really terrible errors we already assert() or abort() on
4932017-03-30T19:44:36 <jeremyrubin> and if we're shutting down gracefully, write to a file "was graceful"
4942017-03-30T19:44:41 <BlueMatt> gmaxwell: AbortNode() is usually disk corruption
4952017-03-30T19:44:45 <jeremyrubin> On next start, show dialogue first thing?
4962017-03-30T19:44:46 <wumpus> please don't make it routine to abort() for everything
4972017-03-30T19:44:53 <wumpus> only for things that really warrant it
4982017-03-30T19:45:00 <wumpus> not crash on every single error
4992017-03-30T19:45:02 <BlueMatt> or too little disk space
5002017-03-30T19:45:02 <sdaftuar> or too little disk space, not quite teh same as corruption
5012017-03-30T19:45:03 <wumpus> that's just a mess
5022017-03-30T19:45:13 *** PaulCapestany has joined #bitcoin-core-dev
5032017-03-30T19:45:21 <gmaxwell> okay, sure.
5042017-03-30T19:45:24 <wumpus> for some problems it's fine to try to clean up normally
5052017-03-30T19:45:31 <wumpus> but we still need to exit with a message
5062017-03-30T19:45:34 <wumpus> that's what abortnode is for
5072017-03-30T19:45:50 *** mol has quit IRC
5082017-03-30T19:45:56 <wumpus> if BlueMatt can make it work faster that's great, but don't silently kill the program on every error
5092017-03-30T19:46:08 *** CubicEarthh has quit IRC
5102017-03-30T19:46:18 <gmaxwell> wumpus: how about every other error?
5112017-03-30T19:46:26 <gmaxwell> :P
5122017-03-30T19:46:33 <wumpus> gmaxwell: hehe
5132017-03-30T19:46:59 <sipa> do #9208 and #9725 interact?
5142017-03-30T19:47:01 <gribble> https://github.com/bitcoin/bitcoin/issues/9208 | Improve DisconnectTip performance by sdaftuar · Pull Request #9208 · bitcoin/bitcoin · GitHub
5152017-03-30T19:47:03 <gribble> https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt · Pull Request #9725 · bitcoin/bitcoin · GitHub
5162017-03-30T19:47:07 <gmaxwell> Y'all so worried about the dressings on the coffin. "It's already dead!" But sure. Sorry I was only thinking of OOM, it's just a recent subject.
5172017-03-30T19:47:19 <BlueMatt> sipa: they dont, afaik, aside from there now being two structs that can be merged
5182017-03-30T19:47:22 <jeremyrubin> I think deleting a file on graceful shutdown should work
5192017-03-30T19:47:42 <jeremyrubin> And then starting when that file is present shows the dialouge rather than starting
5202017-03-30T19:47:46 <BlueMatt> gmaxwell: yea, AbortNode isnt used for thigns like OOM and total death
5212017-03-30T19:47:49 <BlueMatt> disk space also does it
5222017-03-30T19:47:55 <BlueMatt> but it can also be db corruption
5232017-03-30T19:48:13 <jeremyrubin> This means you don't do anything at all on the Abort, but requires the user to restart their node to see the message
5242017-03-30T19:48:15 <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
5252017-03-30T19:48:31 <wumpus> BlueMatt: yes, makes sense to me
5262017-03-30T19:48:33 <wumpus> BlueMatt: or add a flag
5272017-03-30T19:48:38 <morcos> I haven't really thought this all the way through, but doesn't it seem that as we move more and more towards things happening in other threads, that you'd rather let those threads finish what they are doing
5282017-03-30T19:48:45 <gmaxwell> BlueMatt: you could also harden things up against your current concer by having the rpc stuff always check the shutdown flag right after taking cs_main (whenever it does)?
5292017-03-30T19:48:47 <morcos> If you're committing wallet changes for instance
5302017-03-30T19:48:59 <gmaxwell> BlueMatt: and if it finds out that its on its way down, just returning at that point.
5312017-03-30T19:49:06 <wumpus> in the long run morcos we should move toward looser coupling of things
5322017-03-30T19:49:09 <wumpus> I agree
5332017-03-30T19:49:13 <BlueMatt> gmaxwell: yea, I'm worried that if we start down that path we have to check it everywhere
5342017-03-30T19:49:22 <BlueMatt> eg wallet may make decisions based on some corrupted mempool state
5352017-03-30T19:49:27 <morcos> Let's say you just got some new address from the wallet, and the wallet hasn't committed that state yet and then you Abort()
5362017-03-30T19:49:31 <BlueMatt> (I havent thought all the way through all the potential issues here, just a potential concern)
5372017-03-30T19:50:19 <wumpus> morcos: luckily we have the keypool to handle that specific contingency
5382017-03-30T19:50:24 <jeremyrubin> Every thread could have their own unique ungraceful-close file that it should delete (via RAII) on clean exit. Starting with any present would show error. Uncoupled!
5392017-03-30T19:50:40 <gmaxwell> morcos: well at least the worst you get there is replay (due to keypool/hdwallets).. though replay can be pretty bad.
5402017-03-30T19:51:11 <wumpus> pretty bad but well at least they will never lose live keys
5412017-03-30T19:51:47 <BlueMatt> jeremyrubin: I have a feeling we can be more agressive on the super-strange issues, afaiu this stuff is pretty much hit just with out-of-disk everything else is rare enough.....
5422017-03-30T19:52:36 <sipa> maybe we should just have some std::atomic<bool> shits_on_fire_yo; which when set prevents RPCs etc
5432017-03-30T19:52:46 <wumpus> jeremyrubin: that's not what I mean with uncoupling, what I mean is that if one thread messes up it doesn't need to take the others with it because it can operate more-or-less independently
5442017-03-30T19:52:58 <gmaxwell> sipa: well shutdown can be more or less that.
5452017-03-30T19:53:14 <sipa> that can even be set from a signal handler
5462017-03-30T19:53:34 <BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
5472017-03-30T19:53:53 <jeremyrubin> sipa: what do you do with an in progress RPC?
5482017-03-30T19:54:04 <BlueMatt> in ShutdownSoon cases (eg out of disk) we're ok to continue and just shut down, i think
5492017-03-30T19:54:08 <sipa> jeremyrubin: we can only do so much
5502017-03-30T19:54:08 <wumpus> you can't generally break off an in-progress RPC
5512017-03-30T19:54:11 <BlueMatt> in other cases, we can just assert(false)
5522017-03-30T19:54:13 <wumpus> although some will pay attention to fShutdown
5532017-03-30T19:54:15 <BlueMatt> because they're super rare anyway
5542017-03-30T19:54:21 <jeremyrubin> wumpus: ^ yes, O
5552017-03-30T19:54:21 <gmaxwell> but really, what probably should be done is having the rpcs being able to handle being told "No, you can't have access to [whatever chain state you wanted] right now." then these error conditions that could leave them unstable... could set them.
5562017-03-30T19:54:26 <BlueMatt> and if your disk is corrupted we probably shouldnt be flushing wallet and chainstate as a part of shutdown anyway
5572017-03-30T19:54:47 <BlueMatt> gmaxwell: yea, but thats a huge rewrite for cases that should be super rare
5582017-03-30T19:55:11 <gmaxwell> Or we take a whole different approach to failure messages, .e.g. wrap bitcoin-qt in another program that when qt exists it can go through the logs and give you a useful error. (though this doesn't answer morcos' wallet flush, but really that should be in another process.)
5592017-03-30T19:55:26 <wumpus> BlueMatt: I think there should be a clear separation between (A) I/O issues such as out of disk spae, which just happen regularly (B) rare implementation issues such as internal consistency errors
5602017-03-30T19:55:27 <cfields> iirc rpc has a IsRPCShuttingDown() or so, but only a few things (gbt only, maybe?) checks it
5612017-03-30T19:55:28 <jeremyrubin> wumpus: * yes, I'm aware that isn't quite what you meant, just making noise about having a graceful shutdown file because I think it's a reasonable way to mark if a node shut down dirty
5622017-03-30T19:55:44 <wumpus> (A) normal errors should just give the user an error as AbortNode does now and shut down properly
5632017-03-30T19:56:02 <wumpus> (B) internal state corruption errors could break off the process immediately
5642017-03-30T19:56:02 <gmaxwell> It's obnoxious that we can't preallocate resources such that we can guarentee that we never take a failure at an inoppturtune time.
5652017-03-30T19:56:14 <gmaxwell> having to slather the code in error handling to deal with that is not ideal.
5662017-03-30T19:56:41 <jeremyrubin> gmaxwell: you can preallocate lots of things?
5672017-03-30T19:56:44 <gmaxwell> wumpus: "I had to abort processing a block" is a weak kind of internal state corruption. It leaves assumed invariants violated.
5682017-03-30T19:56:57 <gmaxwell> jeremyrubin: in particular we can't make leveldb's disk usage constant.
5692017-03-30T19:56:58 <BlueMatt> wumpus: yes, thats my proposal
5702017-03-30T19:57:12 <BlueMatt> wumpus: but, specifically, B would include things like chainstate-on-disk-corruption
5712017-03-30T19:57:17 <BlueMatt> which it already partially does, just not completely
5722017-03-30T19:57:26 <wumpus> having code to handle normal errors is perfectly normal and all code has that, I agree that paranoid memory/disk corruption errors tend not to be possible to handle in a sane way
5732017-03-30T19:57:33 <wumpus> BlueMatt: yes
5742017-03-30T19:57:48 <BlueMatt> ok, soooo, acks on:<BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
5752017-03-30T19:58:07 <wumpus> BlueMatt: as I said beforer, yes, that or add a flag/criticality level
5762017-03-30T19:58:11 <BlueMatt> s/use make sure/make sure/
5772017-03-30T19:58:15 <jeremyrubin> BlueMatt: maybe if you paste it again
5782017-03-30T19:58:15 <BlueMatt> sure, that too
5792017-03-30T19:58:23 <BlueMatt> jeremyrubin: ok, <BlueMatt> ok, soooo, acks on:<BlueMatt> <BlueMatt> so maybe the solution is AbortNode gets renamed to ShutdownSoon() and use make sure disk corruption is something different?
5802017-03-30T19:58:39 <gmaxwell> wumpus: for example, if we run out of space while flushing our view of the blockchain will be corrupt, and information about the blockchain from rpcs will be wrong. In a world where error handling is free, every code path that gets access to the blockchain data would be able to gracefully handle being told it's just not available. But I think that would be an unreasonable and dangerous amount
5812017-03-30T19:58:45 <gmaxwell> of complexity. :(
5822017-03-30T19:58:50 <BlueMatt> wumpus: I missed that statement, but, yes
5832017-03-30T19:59:00 <gmaxwell> BlueMatt: that sounds okay to me. but I don't know that diskfull is really a shutdown soon though we really do need to give it a nice message. :(
5842017-03-30T19:59:03 <wumpus> gmaxwell: note that the out-of-disk error happens *before* the disk is entirely full
5852017-03-30T19:59:04 <jeremyrubin> BlueMatt: sgtm
5862017-03-30T19:59:12 <wumpus> gmaxwell: there's a threshold
5872017-03-30T19:59:22 <wumpus> gmaxwell: so that should already be mitigated
5882017-03-30T19:59:26 <gmaxwell> wumpus: yes, but it's not atomic. you can't check and then successfully allocate space.
5892017-03-30T19:59:38 <wumpus> no, it's not perfect, but it works pretty well
5902017-03-30T19:59:43 <wumpus> I've never had corruption on full disk
5912017-03-30T20:00:33 <wumpus> also leveldb write failing shouldn't generally be fatal
5922017-03-30T20:00:39 <gmaxwell> on my desktop, which runs with debug=1 it almost always gets checked at the start of the flush. It doesn't corrupt things on disk, but as matt points out the rpc would return somewhat incorrect results during that time.
5932017-03-30T20:00:39 <wumpus> it just means the last transaction is not committed
5942017-03-30T20:01:00 <jtimon> it seems it's time to abort the meeting
5952017-03-30T20:01:06 <wumpus> #endmeeting
5962017-03-30T20:01:06 <lightningbot> Meeting ended Thu Mar 30 20:01:06 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5972017-03-30T20:01:06 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-30-19.01.html
5982017-03-30T20:01:06 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-30-19.01.txt
5992017-03-30T20:01:06 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-30-19.01.log.html
6002017-03-30T20:01:17 <BlueMatt> wumpus: we need to change that to #abort()
6012017-03-30T20:01:20 <gmaxwell> But I wanted to cleanly flush!
6022017-03-30T20:02:01 <bitcoin-git> [bitcoin] theuni opened pull request #10129: scheduler: fix sub-second precision with boost < 1.50 (master...fix-scheduler-millisecs) https://github.com/bitcoin/bitcoin/pull/10129
6032017-03-30T20:02:26 <cfields> BlueMatt: ^^ fixes the ramped-up cpu issue
6042017-03-30T20:03:00 <wumpus> cfields: 10129 needs backport I suppose?
6052017-03-30T20:03:01 <BlueMatt> cfields: ahh, lol, I dont have old boost
6062017-03-30T20:03:12 <BlueMatt> wumpus: only if we also backport the wallet-flush-in-cscheduler, probably?
6072017-03-30T20:03:18 <BlueMatt> (which i think we should, but....)
6082017-03-30T20:03:26 <BlueMatt> questionable given boost issues
6092017-03-30T20:03:28 <wumpus> eh no, let's not do that, sorry
6102017-03-30T20:03:31 <cfields> wumpus: won't hurt, but doesn't currently matter
6112017-03-30T20:04:09 <BlueMatt> wumpus: fair, yea
6122017-03-30T20:04:12 <cfields> wumpus: probably best to go ahead and backport, just in case any other stuff is backported in the future that relies on the correct behavior
6132017-03-30T20:04:26 <BlueMatt> yea, i mean if it turns out there are complications and its not dead simple, not backporting seems like the best idea
6142017-03-30T20:04:34 <gmaxwell> wallet-flush-in-cscheduler removes a thread?
6152017-03-30T20:04:38 <wumpus> cfields: I assued that was the point because one of your other pulls changes the times to std::chrono instead
6162017-03-30T20:04:47 <wumpus> this one is backportable at least
6172017-03-30T20:05:24 <cfields> wumpus: yes, and BlueMatt was discussing possibly backporting other scheduler changes. Was just being proactive :)
6182017-03-30T20:05:27 <gmaxwell> if wallet-flush-in-cscheduler reduces the thread count, then it's also perhaps interesting in a backport. (less memory / address space!)
6192017-03-30T20:05:30 <wumpus> gmaxwell: it does, but imo it's too risky to backport, we're not entirely sure of it yet this might be only the first issue with it
6202017-03-30T20:05:34 <gmaxwell> aww
6212017-03-30T20:05:35 <gmaxwell> :P
6222017-03-30T20:05:44 <gmaxwell> K
6232017-03-30T20:06:04 <BlueMatt> gmaxwell: yea, thats why i was proposing backport....but its not simple, apparently, because boost :(
6242017-03-30T20:06:21 <wumpus> I've always been kind of wary of cscheduler
6252017-03-30T20:06:32 <BlueMatt> wumpus: yea.....
6262017-03-30T20:06:34 <gmaxwell> yea... well we've had a lot of problems with it in the past.
6272017-03-30T20:06:35 <wumpus> there's been lots of issues with it historically at least in the tests
6282017-03-30T20:06:36 <wumpus> yes
6292017-03-30T20:06:39 <cfields> wumpus: same. even moreso after diving in to debug that one.
6302017-03-30T20:07:06 <cfields> in fairness though, i think many issues have been boost-related
6312017-03-30T20:07:19 <gmaxwell> the general idea of having all the rare periodic stuff in a thread that handles them, is perfectly reasonsble.
6322017-03-30T20:07:25 <wumpus> yes, and most bugs don't show up in our actual single-threaded usage
6332017-03-30T20:07:54 <cfields> wumpus: right. I'd be very wary of adding a second thread. I'd expect to uncover a bug or two for sure.
6342017-03-30T20:08:13 <wumpus> yes, the idea is reasonable
6352017-03-30T20:08:14 <gmaxwell> oh we were thinking about adding another thread to service the schedueler?
6362017-03-30T20:08:47 <cfields> gmaxwell: that's how it's designed, anyway
6372017-03-30T20:08:54 <wumpus> gmaxwell: nonono, please not, it's just that it was designed to be able to work with multiple threads, but that functionality has never been properly verified
6382017-03-30T20:08:58 *** BCBot has quit IRC
6392017-03-30T20:09:04 <gmaxwell> yea, well I think thats a bad idea.
6402017-03-30T20:09:21 <wumpus> there used to be a test that tested it with multiple threads, but that failed randomly and we never found out why
6412017-03-30T20:09:34 *** echonaut has quit IRC
6422017-03-30T20:09:36 <gmaxwell> At least it always seemed to be that the whole utility for such a thing is periodic things that don't have strong realtime requirements.
6432017-03-30T20:09:51 <BlueMatt> wumpus: sounds like its time to just rewrite the thing from scratch just because....
6442017-03-30T20:10:02 <wumpus> BlueMatt: or just drop the mult-thread functionality
6452017-03-30T20:10:26 <BlueMatt> well, ok, that too
6462017-03-30T20:10:37 <wumpus> I think it could be shortened a lot with c++11 functionality like lambdas and tasks etc
6472017-03-30T20:10:44 *** nemgun has joined #bitcoin-core-dev
6482017-03-30T20:10:48 <BlueMatt> i mean whatever, leave it there, I plan on moving lots of things to cscheduler, just will have to make it sane before turning it on
6492017-03-30T20:10:52 <BlueMatt> ie c++11 stuff, probably
6502017-03-30T20:11:15 *** MarcoFalke_lab has quit IRC
6512017-03-30T20:11:35 <gmaxwell> the periodic wallet flush is seperate from the realtime wallet flush that happens after issuing a key or whatever, right?
6522017-03-30T20:11:37 <cfields> std::map<std::chrono::time_point, std::packaged_task> done :)
6532017-03-30T20:12:27 <wumpus> same for the closure stuff and worker queue in http_server
6542017-03-30T20:12:27 <gmaxwell> well it should be a min-heap, :P I'm sure there is one of those in stl no?
6552017-03-30T20:13:09 <BlueMatt> gmaxwell: by "wallet flush", I mean "wallet compaction"
6562017-03-30T20:13:11 <wumpus> no, stl does not have heap types afaik
6572017-03-30T20:13:18 <BlueMatt> wallet flush, indeed, is the thing that happens when you write something directly
6582017-03-30T20:13:23 <wumpus> boost does *ducks*
6592017-03-30T20:13:31 <wumpus> yes please call it compaction not flush
6602017-03-30T20:13:47 *** BCBot has joined #bitcoin-core-dev
6612017-03-30T20:14:00 <gmaxwell> BlueMatt: okay sounds fine then... not the stuff that we need a critical realtime response on.
6622017-03-30T20:14:40 <wumpus> yes
6632017-03-30T20:15:19 <BlueMatt> indeed, the function name changed to compaction from flush when it moved into cscheduler
6642017-03-30T20:15:24 <BlueMatt> because thats a more accurate description
6652017-03-30T20:15:36 <bitcoin-git> [bitcoin] gmaxwell reopened pull request #9424: Change LogAcceptCategory to use uint32_t rather than sets of strings. (master...log_category_simplify) https://github.com/bitcoin/bitcoin/pull/9424
6662017-03-30T20:21:04 *** echonaut has joined #bitcoin-core-dev
6672017-03-30T20:22:43 <wumpus> I don't think I remember ever seeing that pull before. Then again, so many pulls get openened, it's easy to lose track :/
6682017-03-30T20:24:08 <wumpus> oh end of dec 2016, yea, wasn't too active at that time
6692017-03-30T20:24:10 *** molz_ has quit IRC
6702017-03-30T20:24:38 *** molz_ has joined #bitcoin-core-dev
6712017-03-30T20:27:23 *** nemgun has quit IRC
6722017-03-30T20:32:08 *** PaulCape_ has joined #bitcoin-core-dev
6732017-03-30T20:33:28 *** PaulCapestany has quit IRC
6742017-03-30T20:38:43 *** cdecker has quit IRC
6752017-03-30T20:42:14 <bitcoin-git> [bitcoin] jnewbery opened pull request #10130: bitcoin-tx input verification (master...bitcoin_tx_input_sanitiser) https://github.com/bitcoin/bitcoin/pull/10130
6762017-03-30T20:45:01 *** cdecker has joined #bitcoin-core-dev
6772017-03-30T20:48:03 <phantomcircuit> wait there's an issue with flush in csceduler?
6782017-03-30T20:49:46 <cfields> phantomcircuit: only with old boost
6792017-03-30T20:51:52 <phantomcircuit> oh
6802017-03-30T20:56:27 *** laurentmt has quit IRC
6812017-03-30T21:01:47 *** jannes has quit IRC
6822017-03-30T21:15:03 *** nabu has joined #bitcoin-core-dev
6832017-03-30T21:31:05 <achow101> if a ping message is sent, but a pong is not received, will other messages still be sent to the pinged node until the ping timeout?
6842017-03-30T21:38:01 <sipa> yes
6852017-03-30T21:38:40 <achow101> interesting, I'm not seeing that on wireshark..
6862017-03-30T21:39:33 <achow101> for that matter, I don't see the ping in question being sent, I just see it in the debug.log
6872017-03-30T21:52:05 *** magicwund has quit IRC
6882017-03-30T22:08:19 *** Guyver2 has quit IRC
6892017-03-30T22:27:34 *** Cory has quit IRC
6902017-03-30T22:41:24 *** vicenteH has quit IRC
6912017-03-30T22:50:06 *** Cory has joined #bitcoin-core-dev
6922017-03-30T23:08:04 *** alpalp has joined #bitcoin-core-dev
6932017-03-30T23:08:04 *** alpalp has joined #bitcoin-core-dev
6942017-03-30T23:09:42 <bitcoin-git> [bitcoin] fanquake closed pull request #10106: bitcoin-tx: Fix missing range check (master...bitcointx-addoutaddr) https://github.com/bitcoin/bitcoin/pull/10106
6952017-03-30T23:23:19 *** goksinen has joined #bitcoin-core-dev
6962017-03-30T23:51:33 *** bityogi has quit IRC
6972017-03-30T23:54:36 *** abpa has quit IRC