1 2018-05-03 06:08:50	0|wumpus|MarcoFalke: nice, since #13051 it's possible to run individual functional tests in an out-of-tree build without having to manually provide BITCOIND=...
  2 2018-05-03 06:08:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/13051 | qa: Normalize executable location by MarcoFalke · Pull Request #13051 · bitcoin/bitcoin · GitHub
  3 2018-05-03 06:14:43	0|wumpus|though I'm confused how that manages to work, does it store the ini in the source directory?
  4 2018-05-03 09:19:31	0|promag|wumpus: should I close #12507 or it's something that can be merged?
  5 2018-05-03 09:19:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/12507 | Interrupt rescan on shutdown request by promag · Pull Request #12507 · bitcoin/bitcoin · GitHub
  6 2018-05-03 09:26:56	0|wumpus|promag: looks mergeable to me
  7 2018-05-03 09:27:38	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ef006d92845a...2afdc294039f
  8 2018-05-03 09:27:39	0|bitcoin-git|13bitcoin/06master 142afdc29 15Wladimir J. van der Laan: Merge #12507: Interrupt rescan on shutdown request...
  9 2018-05-03 09:27:39	0|bitcoin-git|13bitcoin/06master 14c4fda76 15João Barbosa: wallet: Interrupt rescan on shutdown request
 10 2018-05-03 09:27:43	0|wumpus|promag: I don't really like how everything is gaining a dependency on init.h for ShutdownRequested, but that's an architectural issue that can be solved separately
 11 2018-05-03 09:28:21	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12507: Interrupt rescan on shutdown request (06master...062018-02-shutdown-on-rescan) 02https://github.com/bitcoin/bitcoin/pull/12507
 12 2018-05-03 09:30:30	0|promag|wumpus: yeah that's the way it is atm
 13 2018-05-03 09:31:23	0|promag|wumpus: I also think #12729 is mergeable
 14 2018-05-03 09:31:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/12729 | Get rid of ambiguous OutputType::NONE value by ryanofsky · Pull Request #12729 · bitcoin/bitcoin · GitHub
 15 2018-05-03 09:31:49	0|wumpus|thanks will take a look
 16 2018-05-03 09:53:20	0|bitcoin-git|13bitcoin/06master 141e46d8a 15Russell Yanofsky: Get rid of ambiguous OutputType::NONE value...
 17 2018-05-03 09:53:20	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2afdc294039f...979150bc2388
 18 2018-05-03 09:53:21	0|bitcoin-git|13bitcoin/06master 14979150b 15Wladimir J. van der Laan: Merge #12729: Get rid of ambiguous OutputType::NONE value...
 19 2018-05-03 09:54:04	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12729: Get rid of ambiguous OutputType::NONE value (06master...06pr/nonone) 02https://github.com/bitcoin/bitcoin/pull/12729
 20 2018-05-03 10:24:23	0|antipovka_|Someone asked me about this Satoshi Mine Bot and here it is! this bot simply automate your actions!  It has a lot of settings and actually can help you being fast. But first you have to have your winning strategy! I am not going to explain about it, you are smart people, you are going to handle it! https://www.youtube.com/watch?v=ak-JKQvbDdc&t=7s
 21 2018-05-03 10:33:53	0|promag|wumpus: updated #12639
 22 2018-05-03 10:33:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/12639 | Reduce cs_main lock in listunspent by promag · Pull Request #12639 · bitcoin/bitcoin · GitHub
 23 2018-05-03 10:40:03	0|bitcoin-git|13bitcoin/06master 1421f5680 15Russell Yanofsky: Trivial: s/SetBestChain/ChainStateFlushed in comments after #13106
 24 2018-05-03 10:40:03	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/979150bc2388...11adab39e601
 25 2018-05-03 10:40:04	0|bitcoin-git|13bitcoin/06master 1411adab3 15Wladimir J. van der Laan: Merge #13154: Trivial: s/SetBestChain/ChainStateFlushed in comments after #13106...
 26 2018-05-03 10:40:55	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13154: Trivial: s/SetBestChain/ChainStateFlushed in comments after #13106 (06master...06pr/flushed) 02https://github.com/bitcoin/bitcoin/pull/13154
 27 2018-05-03 10:53:56	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/11adab39e601...b62b437acd44
 28 2018-05-03 10:53:57	0|bitcoin-git|13bitcoin/06master 140bd4cd3 15practicalswift: logging: remove unused return value from LogPrintStr...
 29 2018-05-03 10:53:57	0|bitcoin-git|13bitcoin/06master 1476f344d 15practicalswift: logging: Fix potential use-after-free in LogPrintStr(...)
 30 2018-05-03 10:53:58	0|bitcoin-git|13bitcoin/06master 14b62b437 15Wladimir J. van der Laan: Merge #13148: logging: Fix potential use-after-free in LogPrintStr(...)...
 31 2018-05-03 10:54:51	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13148: logging: Fix potential use-after-free in LogPrintStr(...) (06master...06logprintstr-uaf) 02https://github.com/bitcoin/bitcoin/pull/13148
 32 2018-05-03 12:03:21	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #13157: test: Handle timestamps without microseconds in combine_logs (06master...062018_05_logcombine_timestamps) 02https://github.com/bitcoin/bitcoin/pull/13157
 33 2018-05-03 13:38:01	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b62b437acd44...7eb7076f7007
 34 2018-05-03 13:38:02	0|bitcoin-git|13bitcoin/06master 14a59dac3 15João Barbosa: refactor: Avoid extra lookups of mapAddressBook in listunspent RPC
 35 2018-05-03 13:38:02	0|bitcoin-git|13bitcoin/06master 14d76962e 15João Barbosa: rpc: Reduce cs_main lock in listunspent
 36 2018-05-03 13:38:03	0|bitcoin-git|13bitcoin/06master 147eb7076 15Wladimir J. van der Laan: Merge #12639: Reduce cs_main lock in listunspent...
 37 2018-05-03 13:38:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12639: Reduce cs_main lock in listunspent (06master...062018-03-reduce-cs_main_lock-listunspent) 02https://github.com/bitcoin/bitcoin/pull/12639
 38 2018-05-03 13:44:12	0|promag|wumpus: another one in the same line #12151
 39 2018-05-03 13:44:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/12151 | Remove cs_main lock from blockToJSON and blockheaderToJSON by promag · Pull Request #12151 · bitcoin/bitcoin · GitHub
 40 2018-05-03 13:44:34	0|wumpus|I'm done with locking refactors for a bit :)
 41 2018-05-03 13:44:52	0|promag|ah! out of luck :D
 42 2018-05-03 13:45:15	0|promag|maybe next month :D
 43 2018-05-03 13:46:01	0|wumpus|time to review #12979
 44 2018-05-03 13:46:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into paralell validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
 45 2018-05-03 13:50:51	0|promag|allright :/ heh
 46 2018-05-03 13:56:02	0|BlueMatt|promag: that still makes a ton more sense after 11913
 47 2018-05-03 13:58:53	0|promag|BlueMatt: you mean 12979 after 11913 or 12151 after 11913?
 48 2018-05-03 14:00:08	0|promag|if you mean #12151 then yeah for sure
 49 2018-05-03 14:00:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/12151 | Remove cs_main lock from blockToJSON and blockheaderToJSON by promag · Pull Request #12151 · bitcoin/bitcoin · GitHub
 50 2018-05-03 14:00:49	0|BlueMatt|12151, yea
 51 2018-05-03 14:00:52	0|promag|BlueMatt: 11913 needs rebase
 52 2018-05-03 14:01:15	0|BlueMatt|yea, I've been lazy about rebasing a few of my prs that arent getting review cause some of the other are
 53 2018-05-03 14:01:27	0|BlueMatt|oh, no, that one i should rebase
 54 2018-05-03 14:01:28	0|BlueMatt|ugh, k
 55 2018-05-03 14:19:04	0|bitcoin-git|[13bitcoin] 15marcoagner opened pull request #13158: [qt]: Improve sendcoinsdialog readability (06master...06improve_sendcoinsdialog_readability) 02https://github.com/bitcoin/bitcoin/pull/13158
 56 2018-05-03 15:51:49	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13157: test: Handle timestamps without microseconds in combine_logs (06master...062018_05_logcombine_timestamps) 02https://github.com/bitcoin/bitcoin/pull/13157
 57 2018-05-03 16:08:56	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13159: Don't close old debug log file handler prematurely when trying to re-open (on SIGHUP) (06master...06handle-reopen-failed) 02https://github.com/bitcoin/bitcoin/pull/13159
 58 2018-05-03 16:36:28	0|bitcoin-git|[13bitcoin] 15promag opened pull request #13160: Unlock spent outputs (06master...062018-05-unlock-spent-output) 02https://github.com/bitcoin/bitcoin/pull/13160
 59 2018-05-03 16:42:03	0|promag|rpc and wallet labels ^
 60 2018-05-03 17:21:20	0|bitcoin-git|[13bitcoin] 15real-or-random opened pull request #13161: wallet: Reset BerkeleyDB handle after connection fails (06master...06bdb-reset) 02https://github.com/bitcoin/bitcoin/pull/13161
 61 2018-05-03 17:42:21	0|MarcoFalke|wumpus: (re out of tree tests) It works because test_runner.py is aware of the srcdir
 62 2018-05-03 17:42:37	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #13162: [logging] Don't incorrectly log that REJECT messages are unknown. (06master...06fix_reject_logging) 02https://github.com/bitcoin/bitcoin/pull/13162
 63 2018-05-03 17:42:53	0|wumpus|but I eas not running test runner, that already worked before, but individual tests
 64 2018-05-03 17:42:55	0|MarcoFalke|test_runner is linked from the srcdir, so we can follow that link
 65 2018-05-03 17:43:00	0|MarcoFalke|hmm
 66 2018-05-03 17:43:18	0|MarcoFalke|individual tests are not available in the build dir?
 67 2018-05-03 18:20:58	0|wumpus|MarcoFalke: indeed, so used the full path to the source dir, and it works, no matter whether the current directory is in the build directory or the source one
 68 2018-05-03 18:22:35	0|wumpus|MarcoFalke: apparently I have a test/config.ini in the source dir, pointing to the BUILDDIR
 69 2018-05-03 18:22:48	0|wumpus|MarcoFalke: not sure this is the intention, will wipe it and reconfiguer
 70 2018-05-03 18:22:52	0|MarcoFalke|Yeah, otherwise it would fail
 71 2018-05-03 18:23:05	0|MarcoFalke|the config.ini is required now
 72 2018-05-03 18:23:31	0|wumpus|shouldn't it be in the build dir, though?
 73 2018-05-03 18:24:11	0|wumpus|to be clear I think this is convenient, but it probably breaks the case where one source directory is used with multiple build dirs
 74 2018-05-03 18:31:30	0|wumpus|or when configuring from a read-only source dir
 75 2018-05-03 18:32:16	0|wumpus|ok, after reconfiguring the config.ini appears in the build dir, not the source dir, seems to have been an anomaly
 76 2018-05-03 18:42:31	0|jamesob|cfields: would it make sense to at some point move logging into a separate thread? (about to look at your changes, but was just wondering)
 77 2018-05-03 18:42:49	0|wumpus|MarcoFalke: it looks like 'make clean' does not delete config.ini
 78 2018-05-03 18:43:01	0|MarcoFalke|oh
 79 2018-05-03 18:43:04	0|cfields|jamesob: yea, I think just about everyone has proposed that at some point, but nobody's done it :)
 80 2018-05-03 18:43:06	0|MarcoFalke|and make distclean?
 81 2018-05-03 18:43:20	0|wumpus|MarcoFalke: what happened is probably: I configured the source dir, cleaned that, then configured in a separate build directory
 82 2018-05-03 18:43:33	0|cfields|jamesob: might be a good topic for the meeting today, I'm sure there are lots of thoughts on that
 83 2018-05-03 18:43:33	0|jamesob|cfields: welp, I'll add it to the list :)
 84 2018-05-03 18:43:38	0|MarcoFalke|Yeah, that is what I assumed
 85 2018-05-03 18:43:50	0|jamesob|cfields: cool, will bring it up
 86 2018-05-03 18:43:52	0|wumpus|distclean does remove it
 87 2018-05-03 18:44:16	0|MarcoFalke|Usually you are asked to disclean before doing an out of tree build, at least I am
 88 2018-05-03 18:44:57	0|wumpus|yes
 89 2018-05-03 18:45:05	0|wumpus|I think that makes sense...
 90 2018-05-03 18:54:26	0|sipa|i'm going to be 10-15 min late for keeting
 91 2018-05-03 18:54:28	0|sipa|meeting
 92 2018-05-03 18:57:09	0|wumpus|ok
 93 2018-05-03 18:58:28	0|MarcoFalke|Proposed short topic: Delete 0.8, 0.9 and 0.10 git branches
 94 2018-05-03 18:59:16	0|wumpus|ack
 95 2018-05-03 18:59:23	0|wumpus|oh
 96 2018-05-03 18:59:36	0|lightningbot|Meeting started Thu May  3 19:00:10 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 97 2018-05-03 18:59:36	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 98 2018-05-03 18:59:36	0|wumpus|#startmeeting
 99 2018-05-03 18:59:38	0|promag|hi
100 2018-05-03 18:59:51	0|jamesob|hi
101 2018-05-03 18:59:55	0|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
102 2018-05-03 18:59:58	0|jnewbery|hello
103 2018-05-03 19:00:02	0|kanzure|hi.
104 2018-05-03 19:00:07	0|achow101|hi
105 2018-05-03 19:00:08	0|cfields|hi
106 2018-05-03 19:00:22	0|jonasschnelli|hi
107 2018-05-03 19:00:30	0|jimpo|hi
108 2018-05-03 19:00:32	0|jcorgan|lurking as usual
109 2018-05-03 19:00:49	0|wumpus|any other proposed topics?
110 2018-05-03 19:01:16	0|jamesob|logging at some point?
111 2018-05-03 19:01:30	0|wumpus|what about logging?
112 2018-05-03 19:01:41	0|jamesob|I'd like to talk about moving it into a separate thread
113 2018-05-03 19:01:50	0|wumpus|ok
114 2018-05-03 19:02:03	0|BlueMatt|#12934
115 2018-05-03 19:02:03	0|jnewbery|+1 to moving logging to a separate thread
116 2018-05-03 19:02:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/12934 | [WIP] [net] [validation] Call ProcessNewBlock() asynchronously by skeees · Pull Request #12934 · bitcoin/bitcoin · GitHub
117 2018-05-03 19:02:06	0|wumpus|let's start with the usual topic
118 2018-05-03 19:02:31	0|wumpus|even though it will piss off BlueMatt :)
119 2018-05-03 19:02:32	0|wumpus|#topic High prioriity for review
120 2018-05-03 19:02:40	0|wumpus|https://github.com/bitcoin/bitcoin/projects/8
121 2018-05-03 19:03:17	0|wumpus|only #12979 #12560 #10757 left now
122 2018-05-03 19:03:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into paralell validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
123 2018-05-03 19:03:25	0|gribble|https://github.com/bitcoin/bitcoin/issues/12560 | [wallet] Upgrade path for non-HD wallets to HD by achow101 · Pull Request #12560 · bitcoin/bitcoin · GitHub
124 2018-05-03 19:03:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
125 2018-05-03 19:03:41	0|wumpus|anything to discuss about those?
126 2018-05-03 19:03:51	0|wumpus|anything new to add? or remove?
127 2018-05-03 19:04:14	0|jimpo|I'd like #12254 to get some review :-)
128 2018-05-03 19:04:17	0|gribble|https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
129 2018-05-03 19:04:48	0|jnewbery|There's a whole series of sequential PRs on wallet load/create/unload. It'd be good to start moving through those, but I don't know how high priority they are for others
130 2018-05-03 19:05:07	0|wumpus|jnewbery: if it's blocking anyone, the first one on the list should be on there at least
131 2018-05-03 19:05:14	0|jtimon|perhaps put the load one in high priority?
132 2018-05-03 19:05:18	0|jnewbery|#10740
133 2018-05-03 19:05:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] `loadwallet` RPC - load wallet at runtime by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
134 2018-05-03 19:05:40	0|jnewbery|It's only blocking because there are other ones queued behind it
135 2018-05-03 19:05:51	0|BlueMatt|jnewbery: that is the most common form of blocking
136 2018-05-03 19:05:51	0|wumpus|so it's blocking the continuation ones
137 2018-05-03 19:05:59	0|jimpo|That's basically the definition of blocking...
138 2018-05-03 19:06:01	0|wumpus|right, it's pretty much the definition of blocking
139 2018-05-03 19:06:03	0|wumpus|lol
140 2018-05-03 19:06:04	0|jonasschnelli|I agree that we should add 10740 to the list
141 2018-05-03 19:06:11	0|wumpus|#10740 given me an unicorn though
142 2018-05-03 19:06:17	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] `loadwallet` RPC - load wallet at runtime by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
143 2018-05-03 19:06:27	0|jonasschnelli|has also a unicorn, reload solved
144 2018-05-03 19:06:40	0|wumpus|yes
145 2018-05-03 19:06:41	0|LukeJr|unicorns probably have a high street value
146 2018-05-03 19:07:03	0|wumpus|added
147 2018-05-03 19:07:04	0|jnewbery|not any more. The market's been flooded
148 2018-05-03 19:07:14	0|BlueMatt|topic: 0.15.1
149 2018-05-03 19:07:15	0|LukeJr|shows what I know of unicorn markets
150 2018-05-03 19:07:17	0|BlueMatt|err 16
151 2018-05-03 19:07:37	0|wumpus|LukeJr: yes, I"m trying to farm them and sell them, but I have more now than atoms in the knows universe so you could say the supply is more than the demand...
152 2018-05-03 19:07:45	0|promag|wumpus: could also add #13097 too?
153 2018-05-03 19:07:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/13097 | ui: Support wallets loaded dynamically by promag · Pull Request #13097 · bitcoin/bitcoin · GitHub
154 2018-05-03 19:08:23	0|wumpus|promag: ok
155 2018-05-03 19:08:36	0|promag|ty
156 2018-05-03 19:09:00	0|wumpus|#topic Delete 0.8, 0.9 and 0.10 git branches
157 2018-05-03 19:09:08	0|MarcoFalke|Background: Those last tagged versions on those branches are EOL for more than a year now. The tags can be kept for archival reasons, but the branches are no longer required. See https://bitcoincore.org/en/lifecycle/#schedule
158 2018-05-03 19:09:15	0|wumpus|yes
159 2018-05-03 19:09:19	0|BlueMatt|ack
160 2018-05-03 19:09:23	0|wumpus|bye
161 2018-05-03 19:09:25	0|achow101|ack
162 2018-05-03 19:09:27	0|jonasschnelli|ack
163 2018-05-03 19:09:43	0|jtimon|I didn't know we still had those
164 2018-05-03 19:09:43	0|LukeJr|is the latest commit of each tagged?
165 2018-05-03 19:10:00	0|jonasschnelli|LukeJr: i hope so
166 2018-05-03 19:10:00	0|LukeJr|If not, maybe a 0.n_final tag is appropriate
167 2018-05-03 19:10:14	0|wumpus|LukeJr: agree, will check that first
168 2018-05-03 19:10:23	0|cfields|er, are they not tagged from their respective branches?
169 2018-05-03 19:10:31	0|LukeJr|jonasschnelli: it wouldn't be the first time we have backported fixes and never released with them
170 2018-05-03 19:10:32	0|MarcoFalke|LukeJr: For the 0.8 one not
171 2018-05-03 19:10:48	0|MarcoFalke|The others are last tag == tip of branch, last time I checked
172 2018-05-03 19:11:08	0|wumpus|will create a v0.8_final for that
173 2018-05-03 19:11:14	0|wumpus|+tag
174 2018-05-03 19:11:28	0|LukeJr|maybe it can be a non-object tag, to avoid confusing users with a recent date
175 2018-05-03 19:11:58	0|wumpus|yes fine with me, just to avoid losing history
176 2018-05-03 19:12:14	0|MarcoFalke|Oh, and the 0.9 one is missing one commit (upnp)
177 2018-05-03 19:12:31	0|sipa|back
178 2018-05-03 19:12:53	0|wumpus|MarcoFalke: so same for 0.9 then
179 2018-05-03 19:13:29	0|wumpus|#topic Moving logging to a separate thread (jamesob)
180 2018-05-03 19:14:09	0|jamesob|after working on #13099, I think it may be worthwhile to move logging into a separate thread
181 2018-05-03 19:14:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/13099 | Use thread names in logs and deadlock diagnostics by jamesob · Pull Request #13099 · bitcoin/bitcoin · GitHub
182 2018-05-03 19:14:28	0|jamesob|esp. given instances like #12970
183 2018-05-03 19:14:30	0|BlueMatt|ACKACKACKACKACKACKACKACKACKACK (this is a surprisingly high lag-creator for miners, at least for those with spinning-disk-backed-or-cloud-hosted machines
184 2018-05-03 19:14:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/12970 | logging: bypass timestamp formatting when not logging by theuni · Pull Request #12970 · bitcoin/bitcoin · GitHub
185 2018-05-03 19:14:43	0|wumpus|queue log messages to a ring buffer ?
186 2018-05-03 19:14:51	0|jamesob|wumpus: sure, something along those lines
187 2018-05-03 19:14:57	0|wumpus|gmaxwell has been proposing that for ages...
188 2018-05-03 19:15:00	0|BlueMatt|see-also commit which does this at https://github.com/bitcoinfibre/bitcoinfibre/commit/6b6a3aef0663775b63bac7d0aa07ec5fc4eb9fc9
189 2018-05-03 19:15:11	0|jnewbery|I started working on a branch for this last year, but didn't get very far
190 2018-05-03 19:15:17	0|jnewbery|definite concept ACK
191 2018-05-03 19:15:21	0|wumpus|yes, concept ACK
192 2018-05-03 19:15:42	0|BlueMatt|I did not propose it upstream as it means if we LogPrintf(); assert(false) we'll likely miss it
193 2018-05-03 19:15:44	0|jnewbery|means the message processing thread can't be blocked on i/o hangs
194 2018-05-03 19:15:46	0|BlueMatt|and I figured folks wouldnt want that
195 2018-05-03 19:15:56	0|skeees|ACK - should point out that it could make crash debugging substantially more complicated
196 2018-05-03 19:16:05	0|BlueMatt|jnewbery: it still will be a ton cause it ReadBlockFromDisk()s
197 2018-05-03 19:16:06	0|wumpus|BlueMatt: we could have special priority log calls that always make it to disk?
198 2018-05-03 19:16:12	0|jamesob|skeees: right, I think that's the only caveat I can think of
199 2018-05-03 19:16:16	0|LukeJr|BlueMatt: surely there's a way to run log flushing at assert
200 2018-05-03 19:16:18	0|wumpus|BlueMatt: CriticalLogPrintf?
201 2018-05-03 19:16:19	0|promag|+1 BlueMatt point
202 2018-05-03 19:16:22	0|cfields|are there any possible interactions where someone might be tailing the log and assume that it's synchronous?
203 2018-05-03 19:16:29	0|jonasschnelli|use gdb
204 2018-05-03 19:16:40	0|BlueMatt|wumpus: I mean the number of times its been helpful just to see which lines actually made it to debug.log when someone submitted a crash is super helpful
205 2018-05-03 19:16:47	0|LukeJr|cfields: it couldn't be?
206 2018-05-03 19:16:51	0|BlueMatt|and gdb isnt really an option when debugging remotely over github issues :/
207 2018-05-03 19:16:58	0|jimpo|Does anyone know the relative performance of logging to console vs debug log file?
208 2018-05-03 19:17:16	0|BlueMatt|jimpo: on non-serial-consoles, console logging should be fast, serial consoles can block
209 2018-05-03 19:17:20	0|LukeJr|in theory, we could fork() a logging-only process, but that feels ugly
210 2018-05-03 19:17:21	0|BlueMatt|(or vtt on a slow-refresh-monitor)
211 2018-05-03 19:17:25	0|sipa|We should fork a separate process for logging, and then open a FIFO with it and pipe the log data there. If bitcoind crashes, that process hopefully survives :)
212 2018-05-03 19:17:28	0|gribble|Error: "hi5" is not a valid command.
213 2018-05-03 19:17:28	0|sipa|!hi5 LukeJr
214 2018-05-03 19:17:43	0|wumpus|it's mostly a win for low priority debugging messages, I guess
215 2018-05-03 19:17:47	0|BlueMatt|or we could just make it optional
216 2018-05-03 19:17:52	0|wumpus|if logging is low volume it's never a bottleneck
217 2018-05-03 19:18:00	0|BlueMatt|miners can enable it, everyone else probably doesnt need to
218 2018-05-03 19:18:12	0|wumpus|only miners that have debug=net enabled?
219 2018-05-03 19:18:17	0|skeees|just throwing out some alternatives with a properly tuned buffer cache - logging shouldn't hit disk that often? if its still flushing frequently - could consider a more compact binary format for logs - though that means you'd need a special tool to read them
220 2018-05-03 19:18:44	0|jimpo|I feel like disabling logging to file and piping stdout through tee or something should work fine
221 2018-05-03 19:19:03	0|wumpus|skeees: well the logging is unbuffered at this moment so can't do much worse than that...
222 2018-05-03 19:19:04	0|BlueMatt|wumpus: I mean -debug should always mean non-async loggin, I think
223 2018-05-03 19:19:16	0|cfields|skeees: it's not just hitting disk, it's serialization as well. Though I guess we couldn't defer serialization if references are passed in.
224 2018-05-03 19:19:17	0|wumpus|even line-buffered would be better for performance
225 2018-05-03 19:19:37	0|jamesob|wumpus: I thought fwrite was buffered?
226 2018-05-03 19:19:38	0|wumpus|BlueMatt: right
227 2018-05-03 19:19:40	0|skeees|another option is to have debug logging compiled out
228 2018-05-03 19:19:50	0|skeees|instead of just disabled via flag as it is currently
229 2018-05-03 19:19:55	0|wumpus|jamesob: yes, but the buffer is disabled after opening
230 2018-05-03 19:20:05	0|BlueMatt|I mean I dont think people who want performance dont want a debug.log
231 2018-05-03 19:20:13	0|BlueMatt|they just dont want it to result in 8-ms pauses
232 2018-05-03 19:20:25	0|wumpus|skeees: that's not the issue; debug logging is already not executed if it's disabled
233 2018-05-03 19:20:34	0|wumpus|skeees: even formatting is bypassed in that case
234 2018-05-03 19:20:45	0|wumpus|LukeJr: yes
235 2018-05-03 19:20:49	0|skeees|LukeJr: yeah that's exactly the question i was trying to ask
236 2018-05-03 19:20:52	0|skeees|ah ok
237 2018-05-03 19:21:23	0|skeees|i dunno actually
238 2018-05-03 19:21:28	0|wumpus|tbh I don't think there's an actual issue here
239 2018-05-03 19:21:35	0|skeees|because theres a lot of uint256.ToString() stuff
240 2018-05-03 19:21:41	0|cfields|operations on incoming vars aren't skipped though, I believe. Like LogPrint("foo: %s", foo.get())
241 2018-05-03 19:21:44	0|BlueMatt|the only issue here is for folks who care a shitload about small disk pauses
242 2018-05-03 19:21:47	0|wumpus|although the ring buffer would be nice because of gmaxwell's argument (log at higher debug message, but don't log the messages to disk unless a crash)
243 2018-05-03 19:21:48	0|BlueMatt|hence why I use it in fibre
244 2018-05-03 19:22:24	0|BlueMatt|when we get ReadBlockFromDisk to be async for peer handling, then it may make more sense to revisit this
245 2018-05-03 19:22:36	0|wumpus|so a crash would log the last low-priority debug messages even if debugging is disabled.. then agian, it's not possible to bypass formatting anymore in that case
246 2018-05-03 19:22:50	0|BlueMatt|we'd have to swap assert() for dump_log_and_crash()
247 2018-05-03 19:23:01	0|wumpus|not sure that even requires logging to be in a sepaerate thread
248 2018-05-03 19:23:07	0|LukeJr|wumpus: not sure if formatting is a big deal tbh
249 2018-05-03 19:23:15	0|LukeJr|BlueMatt: or handle SIGABRT?
250 2018-05-03 19:23:17	0|BlueMatt|no, but then I dont get to upstream my lockless ring buffer logger :p
251 2018-05-03 19:23:19	0|wumpus|LukeJr: well some messages are extremely high volume
252 2018-05-03 19:23:27	0|BlueMatt|luke-jr: I dont think we want to do that much work in a signal handler
253 2018-05-03 19:23:28	0|wumpus|LukeJr: try enabling *all* debugging for fun
254 2018-05-03 19:23:56	0|BlueMatt|matt@bitcoin-seednode:~$ ls -lha ~/.bitcoin/debug.log
255 2018-05-03 19:23:56	0|BlueMatt|-rw------- 1 matt matt 8.6T May  3 19:24 /home/matt/.bitcoin/debug.log
256 2018-05-03 19:24:06	0|wumpus|heh
257 2018-05-03 19:24:17	0|sipa|how long?
258 2018-05-03 19:24:19	0|LukeJr|BlueMatt: if it's plain old C code, we can probably get away with it
259 2018-05-03 19:24:30	0|wumpus|hence my proposal at some point to split up net logging into low and high volume messages
260 2018-05-03 19:24:48	0|BlueMatt|sipa: 2014-11-19 00:06:55
261 2018-05-03 19:24:52	0|wumpus|#12219
262 2018-05-03 19:24:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/12219 | More granular net logging · Issue #12219 · bitcoin/bitcoin · GitHub
263 2018-05-03 19:25:06	0|cfields|wumpus: +1. Will have a look.
264 2018-05-03 19:25:27	0|BlueMatt|I do like the flush-debug-ring-to-disk-on-crash idea
265 2018-05-03 19:25:34	0|jamesob|+1
266 2018-05-03 19:25:34	0|wumpus|yes
267 2018-05-03 19:25:49	0|BlueMatt|(would mean serializing all debug messages, though)
268 2018-05-03 19:26:04	0|LukeJr|maybe even on non-crash critical errors
269 2018-05-03 19:26:22	0|BlueMatt|non-crash critical errors should crash :p
270 2018-05-03 19:26:34	0|wumpus|it's in the word 'critical'
271 2018-05-03 19:27:20	0|jamesob|okay so unless anyone has any objections, I'll start working on a thread-consumes-from-ring-buffer implementation in the near future
272 2018-05-03 19:27:30	0|wumpus|I think I killed the topic
273 2018-05-03 19:27:30	0|wumpus|oh
274 2018-05-03 19:27:36	0|jnewbery|jamesob: ACK
275 2018-05-03 19:27:46	0|BlueMatt|jamesob: I think only as optional except for disabled-debug-messages
276 2018-05-03 19:28:03	0|BlueMatt|jamesob: but if upstream wants to maintain by fibre patches, fine by me :p
277 2018-05-03 19:28:03	0|jamesob|i.e. async logging should be opt-in?
278 2018-05-03 19:28:06	0|BlueMatt|yes
279 2018-05-03 19:28:13	0|BlueMatt|also, you may want to start with https://github.com/bitcoinfibre/bitcoinfibre/commit/6b6a3aef0663775b63bac7d0aa07ec5fc4eb9fc9
280 2018-05-03 19:28:33	0|jamesob|I'll give it a look, thanks
281 2018-05-03 19:29:07	0|wumpus|#topic 0.16.1 (BlueMatt)
282 2018-05-03 19:29:31	0|BlueMatt|so for those who weren't paying attention, skeees found some particularly novel races in block handling in #13092
283 2018-05-03 19:29:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/13092 | ActivateBestChain concurrency issues · Issue #13092 · bitcoin/bitcoin · GitHub
284 2018-05-03 19:29:47	0|BlueMatt|cause they're threading issues they almost certainly wont effect anyone except submitblock users
285 2018-05-03 19:29:55	0|BlueMatt|ie miners, and only rare races
286 2018-05-03 19:30:08	0|BlueMatt|but, still, I think given that and some of the other various fixes we've had, it may be worth backporting
287 2018-05-03 19:30:36	0|wumpus|13092 is an issue, not a PR, can't label it for backport
288 2018-05-03 19:30:39	0|BlueMatt|further, at least personally, I'd kinda like to see #11423 make some movement, and making that kind of policy change in a non-minor-version strikes me as weird
289 2018-05-03 19:30:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/11423 | [Policy] Make OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-std by jl2012 · Pull Request #11423 · bitcoin/bitcoin · GitHub
290 2018-05-03 19:30:50	0|BlueMatt|yes, it needs a pr, sdaftuar has a branch, I believe, but not open
291 2018-05-03 19:31:01	0|sdaftuar|skeees has a pr, one sec
292 2018-05-03 19:31:12	0|sdaftuar|#13023
293 2018-05-03 19:31:12	0|skeees|#13023
294 2018-05-03 19:31:13	0|BlueMatt|was the skeees pr updated for the new method?
295 2018-05-03 19:31:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/13023 | Always refresh most work chain when reacquiring cs_main in ActivateBestChain() by skeees · Pull Request #13023 · bitcoin/bitcoin · GitHub
296 2018-05-03 19:31:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/13023 | Always refresh most work chain when reacquiring cs_main in ActivateBestChain() by skeees · Pull Request #13023 · bitcoin/bitcoin · GitHub
297 2018-05-03 19:31:21	0|sdaftuar|no we need to settle on the right fix
298 2018-05-03 19:31:26	0|skeees|still needs a bit of work - i need to pull in some fixes @sdaftuar made
299 2018-05-03 19:31:34	0|sdaftuar|i think the fix i proposed works, but maybe someone has a better idea
300 2018-05-03 19:31:52	0|BlueMatt|ok, yes, I think that is doable, however, and I think between that and making progress on the standardness changes from jl2012 probably are worth a minor bump
301 2018-05-03 19:31:52	0|wumpus|ok added tags
302 2018-05-03 19:32:02	0|skeees|there's also #12988 - which is a similar type of bug
303 2018-05-03 19:32:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/12988 | Hold cs_main while calling UpdatedBlockTip() signal by skeees · Pull Request #12988 · bitcoin/bitcoin · GitHub
304 2018-05-03 19:32:32	0|BlueMatt|yes, indeed, that too
305 2018-05-03 19:32:43	0|sdaftuar|agreed
306 2018-05-03 19:32:56	0|wumpus|ok
307 2018-05-03 19:33:20	0|BlueMatt|(so, obviously, for those following along at home, next-milestone usually gets auto-high-priority-for-review status :p)
308 2018-05-03 19:33:45	0|wumpus|re: #11423, I rebased that one for jl2012, not sure if there's further things to be done there
309 2018-05-03 19:33:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/11423 | [Policy] Make OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-std by jl2012 · Pull Request #11423 · bitcoin/bitcoin · GitHub
310 2018-05-03 19:34:37	0|wumpus|added 0.16.1 tag there too
311 2018-05-03 19:34:44	0|BlueMatt|I believe jl2012 wanted to add one more policy rule there, which should be done, there was a branch floating around but I cant find it atm
312 2018-05-03 19:34:51	0|BlueMatt|anyway, thats for discussion on that pr
313 2018-05-03 19:35:12	0|BlueMatt|I'll ping jl2012 since he's probably asleep
314 2018-05-03 19:35:30	0|BlueMatt|anyway, seems no disagreement, so next topic?
315 2018-05-03 19:35:31	0|wumpus|yes, but it is the open PR with the most (ut)ACKs so I thought it'd be almost ready for merge
316 2018-05-03 19:35:59	0|wumpus|that's why I rebased it with the idea to merge it after final review
317 2018-05-03 19:36:04	0|wumpus|but ok
318 2018-05-03 19:36:20	0|MarcoFalke|Yeah, would need some re-ACKs first, though
319 2018-05-03 19:36:45	0|wumpus|right, but if the goalposts keep moving
320 2018-05-03 19:37:06	0|wumpus|I think we've exhausted all proposed topics
321 2018-05-03 19:37:17	0|MarcoFalke|If there are minor fix ups, they should probably happen soon
322 2018-05-03 19:37:46	0|BlueMatt|oh, no, wait i had another topic
323 2018-05-03 19:37:59	0|BlueMatt|topic: activate segwit
324 2018-05-03 19:38:03	0|BlueMatt|topic 2: <BlueMatt>  #12934
325 2018-05-03 19:38:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/12934 | [WIP] [net] [validation] Call ProcessNewBlock() asynchronously by skeees · Pull Request #12934 · bitcoin/bitcoin · GitHub
326 2018-05-03 19:38:48	0|BlueMatt|its certainly not ready for review, but we should maybe have a discussion about what concurrency across peers is gonna look like
327 2018-05-03 19:38:49	0|wumpus|#topic Call ProcessNewBlock() asynchronously  (skeees)
328 2018-05-03 19:39:05	0|BlueMatt|there are two main approaches, but both end up requiring similar refactors for the majority of their work
329 2018-05-03 19:39:16	0|BlueMatt|in the past I've looked at doing ProcessMessages() in parallel
330 2018-05-03 19:39:33	0|BlueMatt|in this pr skeees moves the validation processing of txn/blocks into a queue and does that in a separate thread
331 2018-05-03 19:39:57	0|sipa|how does that interact with eg sending a ping after a block, and expecting it to be processed after the pong returns?
332 2018-05-03 19:39:59	0|BlueMatt|in both cases, we end up building logic to "pause" processing of a peer until whatever message it just generated has been processed
333 2018-05-03 19:40:01	0|wumpus|that sounds sensible, though I'm really afraid of c++ threading
334 2018-05-03 19:40:08	0|BlueMatt|sipa: ^
335 2018-05-03 19:40:17	0|gmaxwell|Seems like it would add more locking overhead.
336 2018-05-03 19:40:21	0|BlueMatt|(which would also likely be useful for eg ReadBlockFromDisk moving to be more async)
337 2018-05-03 19:40:57	0|BlueMatt|and a ton of logic to move CNodeState out of cs_main (likely by creating a CNodeState2 during transision)
338 2018-05-03 19:40:57	0|sipa|sound reasonable to me
339 2018-05-03 19:41:08	0|BlueMatt|cfields: may have more thoughts
340 2018-05-03 19:41:09	0|sipa|that sounds even better
341 2018-05-03 19:41:13	0|skeees|the other side benefit of this approach is that ultimately it may simplify the concurrency model inside validation
342 2018-05-03 19:41:18	0|sipa|though everything depends on the details...
343 2018-05-03 19:41:32	0|BlueMatt|gmaxwell: indeed, thats a major difference between the skeees approach and the parallel ProcessMessages approach
344 2018-05-03 19:41:35	0|skeees|having a single thread processing from an ordered queue would have also solved the concurrency issues discussed before
345 2018-05-03 19:41:46	0|BlueMatt|ProcessMessages will still do the work on the processing thread, which should have a bit less locking overhead
346 2018-05-03 19:41:47	0|cfields|BlueMatt: just reading now. at a glance, this approach sounds similar to what I had in mind as well
347 2018-05-03 19:41:53	0|BlueMatt|but is definitely more complicated than the skeees approach
348 2018-05-03 19:42:04	0|BlueMatt|which draws a much cleaner boundary between validation and net_processing
349 2018-05-03 19:42:06	0|gmaxwell|The biggest gain I'm aware of from concurrency is that right now when connecting multiple blocks at a time (due to out of order fetching in IBD) we stop downloading new blocks, ... fixing that would be a big gain; so it might be worth prioritizing improvements that would let that happen.
350 2018-05-03 19:42:19	0|cfields|BlueMatt: I don't see why they'd be mutually exclusive?
351 2018-05-03 19:42:33	0|BlueMatt|gmaxwell: that and relaying compact block gettxn during block connection
352 2018-05-03 19:42:50	0|BlueMatt|which is the one big cheapish win left for block-relay-latency
353 2018-05-03 19:42:54	0|gmaxwell|(e.g. esp when fetching from slow peers, watching network traffic during IBD is comical... transfering at only a couple mbps for a while then nothing for seconds at a time while it connects)
354 2018-05-03 19:42:59	0|BlueMatt|cfields: well doing both is maybe not so useful
355 2018-05-03 19:43:19	0|BlueMatt|since they'd accomplish largely the same thing
356 2018-05-03 19:43:38	0|gmaxwell|BlueMatt: Fair enough for gettxn, though right now my own node makes almost no gettxn requests... and orphaning rates appear to be exceptionally low.
357 2018-05-03 19:43:55	0|gmaxwell|(so what I'm saying is that at the moment I don't think of latency improvements as that critical)
358 2018-05-03 19:43:59	0|BlueMatt|gmaxwell: the skeees approach is certainly better for doing things like deserialization of blocks coming in from other peers while calling ProcessNewBlock/ActivateBestChain
359 2018-05-03 19:44:17	0|BlueMatt|indeed, right now (with mempool ~empty) compact block performance is ~perfect
360 2018-05-03 19:44:21	0|BlueMatt|its not always so, however
361 2018-05-03 19:44:41	0|gmaxwell|hm. interesting point that making deserialization concurrent would potentially be a multi-core gain.
362 2018-05-03 19:44:42	0|BlueMatt|also, fibre nodes see more getblocktxn than miners
363 2018-05-03 19:44:43	0|sipa|by "mempool ~empty" you mean "mempool is a perfect match" ?
364 2018-05-03 19:44:58	0|BlueMatt|which would be equally solved by miners delaying 1 second before including new txn in blocks....
365 2018-05-03 19:45:19	0|gmaxwell|sipa: if each block mostly clears the mempool, miner-specific prioritizaition of transactions doesn't cause as much surprise txn.
366 2018-05-03 19:45:38	0|gmaxwell|BlueMatt: and also making use of the CB facility for transmitting extra txn proactively.
367 2018-05-03 19:45:49	0|BlueMatt|yea, that too
368 2018-05-03 19:46:17	0|BlueMatt|anyway, so tl;dr: I was a bigger fan of the skeees approach and wanted a little bit of concept discussion on the idea of putting a queue in front of the entire validation stuff
369 2018-05-03 19:46:24	0|BlueMatt|since thats a huge departure from current operation
370 2018-05-03 19:46:35	0|BlueMatt|but I think the potential gain is nice
371 2018-05-03 19:46:43	0|BlueMatt|plus all our blocks are already passed in as shared_ptrs anyway.....
372 2018-05-03 19:46:46	0|gmaxwell|so right my point was that speading up IBD is probably a big win, .. improving latency and what not would be nice too but I think it's less important.
373 2018-05-03 19:47:07	0|LukeJr|+1
374 2018-05-03 19:47:09	0|BlueMatt|yes, right now that is definitely true
375 2018-05-03 19:47:17	0|BlueMatt|certainly this has the potential to address both, however
376 2018-05-03 19:47:21	0|gmaxwell|making use of more cores during sync would be nice too, e.g. if deserilization and hashing can happen on seperate threads async with connection.
377 2018-05-03 19:47:38	0|BlueMatt|we can do CheckBlock on the net_processing thread
378 2018-05-03 19:47:52	0|BlueMatt|(since, and sipa is gonna die a little bit inside, here, the result is cached in the CBlock structure)
379 2018-05-03 19:48:10	0|sdaftuar|that is kinda gross :)
380 2018-05-03 19:48:17	0|BlueMatt|its incredibly gross
381 2018-05-03 19:48:25	0|gmaxwell|(e.g. multiple message handling threads, which do deserialization and maybe stateless checks)
382 2018-05-03 19:48:46	0|wumpus|oh no...
383 2018-05-03 19:48:50	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13163: Make it clear which functions that are intended to be translation unit local (06master...06internal-linkage) 02https://github.com/bitcoin/bitcoin/pull/13163
384 2018-05-03 19:49:17	0|gmaxwell|though I did a dumb hack a while back that reordered some of the block validation steps to interleave checks that operate per transaction and got a few percent sync speed improvement... we should be mindful of memory locality and not introduce even more passes over blocks.
385 2018-05-03 19:49:30	0|BlueMatt|gmaxwell: dunno about multiple message handling threads being doable in the immediate future, but doing CheckBlock on the message processing thread (which does merkle root verification, which is a good chunk of the work) may be worth a chunk
386 2018-05-03 19:49:52	0|skeees|cool - so if no strong objections or concerns with the approach i'll continue this and come back when its more ready for review
387 2018-05-03 19:50:33	0|gmaxwell|Funny, I would have thought handling seperate peers in seperate threads would almost just work now, vs stuff that handled messages from the same peer concurrently, which violates protocol assumptions about ordering without special work to add processing barriers.
388 2018-05-03 19:50:50	0|BlueMatt|gmaxwell: CNodeState requires cs_main, so....not even close :(
389 2018-05-03 19:51:05	0|gmaxwell|(almost just work, because the critical data structues have locks ... oh CNodeState)
390 2018-05-03 19:51:11	0|BlueMatt|I've got some old branches that do that, if you want to look
391 2018-05-03 19:51:13	0|gmaxwell|cs_main lite.
392 2018-05-03 19:51:15	0|BlueMatt|but they're....not small changes
393 2018-05-03 19:51:29	0|BlueMatt|and cfields hates them, though he's probably right
394 2018-05-03 19:51:52	0|BlueMatt|anyway, so </topic> </meeting> ["DIE", "XML"]?
395 2018-05-03 19:51:54	0|gmaxwell|in particular our most commons messages are transaction invs and get datas, and those should only need mempool stuff for much of their activity.
396 2018-05-03 19:52:02	0|gmaxwell|k.
397 2018-05-03 19:52:09	0|BlueMatt|gmaxwell: yes, I did all that in an old branch
398 2018-05-03 19:52:17	0|BlueMatt|that in particular is much closer than it used to be
399 2018-05-03 19:52:25	0|BlueMatt|cause now the HandleGetData stuff cant take cs_main at the top
400 2018-05-03 19:52:35	0|BlueMatt|IIRC that refactor landed for 0.16
401 2018-05-03 19:53:34	0|BlueMatt|https://github.com/TheBlueMatt/bitcoin/commits/2017-07-paralell-processmessages-redux
402 2018-05-03 19:54:38	0|gmaxwell|Thanks.
403 2018-05-03 19:55:09	0|BlueMatt|(it got a bunch of time in helgrind, too, and got all the issues fixed, so I'm at least kinda confident in it, but its essentially unreviewable, even by my standards)
404 2018-05-03 19:57:06	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.log.html
405 2018-05-03 19:57:06	0|lightningbot|Meeting ended Thu May  3 19:57:40 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
406 2018-05-03 19:57:06	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.html
407 2018-05-03 19:57:06	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-05-03-19.00.txt
408 2018-05-03 19:57:06	0|wumpus|#endmeeting
409 2018-05-03 19:57:09	0|gmaxwell|I think it would be simpler now, a lot of changes in the last year would have made it easier (I say this without having recently looked at that branch)
410 2018-05-03 19:57:47	0|BlueMatt|yes, I agree
411 2018-05-03 19:57:52	0|BlueMatt|rather significantly
412 2018-05-03 19:58:23	0|BlueMatt|and if we took the "split CNodeState" approach instead of "pull CNodeState above cs_main in global lock order and give it its own lock all in one go" approach that that branch takes, it'd likely be wayyy simpler
413 2018-05-03 20:11:41	0|bitcoin-git|[13bitcoin] 15laanwj 04deleted 060.9 at 14460ccfb: 02https://github.com/bitcoin/bitcoin/commit/460ccfb
414 2018-05-03 20:12:00	0|bitcoin-git|[13bitcoin] 15laanwj 04deleted 060.10 at 149cea169: 02https://github.com/bitcoin/bitcoin/commit/9cea169
415 2018-05-03 20:12:11	0|wumpus|:x
416 2018-05-03 20:12:24	0|sdaftuar|neat
417 2018-05-03 21:20:08	0|bitcoin-git|[13bitcoin] 15jamesob closed pull request #13099: Use thread names in logs and deadlock diagnostics (06master...062018-04-26-use-threadnames) 02https://github.com/bitcoin/bitcoin/pull/13099
418 2018-05-03 21:22:25	0|cfields|jamesob: noo!
419 2018-05-03 21:24:53	0|cfields|jamesob: I hope you don't think I'm being NIH about that PR, that wasn't my intention at all. Coding up an alternative myself helps me to understand the challenges better, it wasn't meant to replace your work.
420 2018-05-03 22:19:47	0|wumpus|"Note: GitHub Services are being deprecated. Please contact your integrator for more information on how to migrate or replace a service to webhooks or GitHub Apps. "
421 2018-05-03 22:20:08	0|wumpus|I wonder if that means the IRC notification bot will disappear
422 2018-05-03 22:21:07	0|luke-jr|isn't it a webhook?
423 2018-05-03 22:22:11	0|wumpus|no
424 2018-05-03 22:22:30	0|wumpus|it's under "integrations and services" which displays that
425 2018-05-03 22:43:13	0|luke-jr|IRC notifications of projects seems to have mostly died with CIA :<
426 2018-05-03 23:38:36	0|jamesob|cfields: oh no not at all! sorry if the PR close came off as me being upset
427 2018-05-03 23:39:39	0|jamesob|cfields: I just like your commits better :). Maybe I can cherry-pick them and then shuffle in my GetProcessName/SetProcessName stuff + some tests
428 2018-05-03 23:40:15	0|jamesob|if that sounds good, would it make sense to repurpose that same PR or open a new one?
429 2018-05-03 23:43:59	0|cfields|jamesob: ok, good
430 2018-05-03 23:44:39	0|cfields|jamesob: if you're going to do away with the suffix handling, I'd say just do a new PR
431 2018-05-03 23:45:15	0|cfields|jamesob: either way, my code is all yours if you like it
432 2018-05-03 23:52:55	0|jamesob|cfields: yeah, should be easy to incorporate the suffix stuff inline as you suggest
433 2018-05-03 23:56:35	0|jamesob|just felt embarrassed I didn't see that earlier :)