1 2018-04-19 00:36:23	0|promag|kallewoof: there is no need to prevent a loop iterating an empty array
  2 2018-04-19 00:37:41	0|kallewoof|promag: Yeah, I was confused. Fixed. :)
  3 2018-04-19 00:37:53	0|promag|cool
  4 2018-04-19 00:38:26	0|promag|I have to test -noincludeconf
  5 2018-04-19 00:38:32	0|promag|didn't thought about that´
  6 2018-04-19 00:38:58	0|kallewoof|Yeah, I didn't think about it either. I think a command line -noincludeconf will actually disable config includeconf. Which.. is good, I think?
  7 2018-04-19 00:41:29	0|kallewoof|No, it seems like -noincludeconf is ignored from command line right now.
  8 2018-04-19 00:41:51	0|promag|really?
  9 2018-04-19 00:42:17	0|kallewoof|It's ignored in bitcoin.conf too. `noincludeconf=1 \n includeconf=relative.conf` will still include relative.conf.
 10 2018-04-19 00:42:58	0|kallewoof|Ah, wait. `includeconf=relative.conf \n noincludeconf=1` will not include relative.conf.
 11 2018-04-19 00:43:57	0|kallewoof|Not sure this is a useful feature at all, to be honest. (-noincludeconf I mean)
 12 2018-04-19 00:52:13	0|aj|kallewoof: foo=bar nofoo=1 foo=baz --> nofoo clears out bar, but then foo=baz gets put in
 13 2018-04-19 00:53:18	0|aj|kallewoof: -nofoo on the commandline would clear out everything for other options
 14 2018-04-19 00:54:11	0|kallewoof|aj: probably because I am loading both kinds manually, but -noincludeconf from cli does not cancel `includeconf=relative.conf` from bitcoin.conf
 15 2018-04-19 00:54:24	0|kallewoof|both kinds = `includeconf` and `[chain].includeconf`
 16 2018-04-19 00:55:52	0|aj|kallewoof: yeah, other options have that taken care of them by the ArgsManager::Get*Arg* functions, you'd have to do it yourself
 17 2018-04-19 00:56:56	0|kallewoof|aj: Gotcha. I think I'll require that `noincludeconf` is not set before doing it, so people can -noincludeconf from command line. Feels buggy otherwise.
 18 2018-04-19 01:00:03	0|kallewoof|promag: I pushed a fix for -noincludeconf
 19 2018-04-19 01:00:32	0|promag|kk
 20 2018-04-19 01:51:23	0|fanquake|eklitzke Good to know you were just travelling. Thought you might have bailed on Core dev after all the slow review turnaround.
 21 2018-04-19 03:01:50	0|bitcoin-git|[13bitcoin] 15tjps opened pull request #13025: Dead code removal (06master...06tjps_dead_code) 02https://github.com/bitcoin/bitcoin/pull/13025
 22 2018-04-19 06:00:01	0|kallewoof|aj: I looked at the seen-txns file you sent me. In combination with block data I should be able to extract what I need I think. For starters I'll make the tool that can read current data, then I will nudge you for data, probably. :)
 23 2018-04-19 07:20:51	0|wumpus|kallewoof: TX_CONF (0x03) has 8 bytes reserved for block height - it's good to plan ahead when designing formats, but 80000 years is maybe a bit much :)
 24 2018-04-19 07:22:22	0|wumpus|kallewoof: also please add some header magic, and a format version
 25 2018-04-19 07:23:37	0|wumpus|kallewoof: especially as the packet types have no framing information of themselves, this means the format is not forward compatible, so readers need to be able to reject newer files
 26 2018-04-19 07:23:51	0|wumpus|(e.g. no way to skip unknown records or fields)
 27 2018-04-19 07:24:35	0|wumpus|(which is a valid decision with regard to storage, but maybe needs to be documented)
 28 2018-04-19 07:31:01	0|bedotech|Hi all, currently bitcoin-core what kind of wallet derivation implement? (for example BIP44 and so on...)
 29 2018-04-19 07:31:39	0|wumpus|bip32 hierarchical deterministic wallet
 30 2018-04-19 07:32:32	0|wumpus|not bip44, you can find the implemented bips in doc/bips.md
 31 2018-04-19 07:32:51	0|bedotech|wumpus: thanks a lot
 32 2018-04-19 07:38:53	0|fanquake|wumpus looks like #12855 is ready to go now that sipa's nit has been fixed
 33 2018-04-19 07:38:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/12855 | net: Minor accumulated cleanups by tjps · Pull Request #12855 · bitcoin/bitcoin · GitHub
 34 2018-04-19 08:00:05	0|bedotech|i want to build a online service that generate address from extended public key, is better to use backward compatibility P2SH-P2WPKH or i can use direct P2WPKH?
 35 2018-04-19 08:00:55	0|fanquake|bedotech ask in #bitcoin
 36 2018-04-19 08:01:12	0|bedotech|fanquake: thanks!
 37 2018-04-19 08:01:30	0|fanquake|or #bitcoin-dev
 38 2018-04-19 09:16:39	0|bitcoin-git|[13bitcoin] 15promag opened pull request #13026: Fix include comment in src/interfaces/wallet.h (06master...062018-04-fixincludecomment) 02https://github.com/bitcoin/bitcoin/pull/13026
 39 2018-04-19 11:29:37	0|jtimon|fixed nits on https://github.com/bitcoin/bitcoin/pull/10757 , in case anyone was waiting for that to review
 40 2018-04-19 12:00:28	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/615f7c288414...39cf27faf324
 41 2018-04-19 12:00:29	0|bitcoin-git|13bitcoin/06master 141bf3f33 15Thomas Snider: node: Removed unused wallet-related methods from the Node interface.
 42 2018-04-19 12:00:29	0|bitcoin-git|13bitcoin/06master 14b382004 15Thomas Snider: benchmark: Removed bench/perf.cpp
 43 2018-04-19 12:00:30	0|bitcoin-git|13bitcoin/06master 1439cf27f 15MarcoFalke: Merge #13025: Dead code removal...
 44 2018-04-19 12:01:24	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13025: Dead code removal (06master...06tjps_dead_code) 02https://github.com/bitcoin/bitcoin/pull/13025
 45 2018-04-19 12:19:36	0|wumpus|MarcoFalke: I don't get it, why are you removing perf.cpp/h?
 46 2018-04-19 12:19:46	0|wumpus|MarcoFalke: is counting cpu cycles no longer relevant?
 47 2018-04-19 12:21:15	0|wumpus|I really don't get this, without any discussion
 48 2018-04-19 12:24:14	0|sipa|wumpus: it seems the code is actually unused
 49 2018-04-19 12:25:03	0|sipa|only perf_init and perf_fini are invoked
 50 2018-04-19 12:25:26	0|sipa|or is your point that we expect to use them again for another purpose soon?
 51 2018-04-19 12:26:01	0|sipa|(i don't have an opinion either way, just want to make sure it's clear what is happening)
 52 2018-04-19 12:30:15	0|MarcoFalke|wumpus: The discussion was in the pull that removed the usage, IIRC
 53 2018-04-19 12:30:40	0|wumpus|it used to be that the benchmarks reported number of cycles too
 54 2018-04-19 12:30:54	0|wumpus|apparently that was changed, and now my code to measure cycles was removed too
 55 2018-04-19 12:30:59	0|wumpus|no one ever asked me about any of this
 56 2018-04-19 12:32:26	0|wumpus|"I have removed the cycles statistics because I personally don't think it is necessary, and it simplifies the code. I could add it back though if others think its a helpful statistic"
 57 2018-04-19 12:32:42	0|wumpus|wtf asked him :/
 58 2018-04-19 12:33:20	0|wumpus|apparently I even reviewed that and missed that
 59 2018-04-19 12:34:58	0|wumpus|but you can't say there really was any discussion
 60 2018-04-19 12:35:06	0|MarcoFalke|fine
 61 2018-04-19 12:35:09	0|MarcoFalke|Is there any evidence that this actually is a statistic that is not redundant?
 62 2018-04-19 12:35:41	0|wumpus|redundant compared to what?
 63 2018-04-19 12:36:11	0|MarcoFalke|std::chrono
 64 2018-04-19 12:36:20	0|MarcoFalke|(the clock we use right now)
 65 2018-04-19 12:36:20	0|wumpus|well std::chrono counts time, not cycles
 66 2018-04-19 12:36:57	0|wumpus|e.g. not when the cpu is actually idle
 67 2018-04-19 12:37:54	0|MarcoFalke|I asssume the only difference would be in the deser block test?
 68 2018-04-19 12:39:24	0|wumpus|I don't know. It's entirely valid to have a discussion about whether it is redundent or not, but I think how this went is absurd
 69 2018-04-19 12:39:58	0|MarcoFalke|It was unused for months now, and no one noticed. I don't think removing the code as it was unused is absurd.
 70 2018-04-19 12:40:05	0|MarcoFalke|I am not saying we can't add it back in
 71 2018-04-19 12:40:37	0|wumpus|right I haven't been using the benchmarks the last months
 72 2018-04-19 12:41:21	0|MarcoFalke|When added back, it should be an optional swich (clock/cycles), so the format doesn't change again
 73 2018-04-19 12:41:58	0|sipa|FWIW, if we continue work on platform specific SHA256 implementations, itay be necessary to do a mini benchmark at startup to determine what is fastest... generally cpu cycles are the most accurate way of doing that
 74 2018-04-19 12:42:28	0|wumpus|well I"m not going to bother that's for sure
 75 2018-04-19 12:42:43	0|wumpus|if I need this again I'll just patch it in locally
 76 2018-04-19 12:42:51	0|MarcoFalke|sipa: That means the fuction should be moved to util.cpp?
 77 2018-04-19 12:42:56	0|sipa|wumpus: i think you're overreacting
 78 2018-04-19 12:43:10	0|sipa|people who reviewed this missed this, and acted in good faith
 79 2018-04-19 12:43:38	0|sipa|we can trivially bring the code back
 80 2018-04-19 12:44:07	0|wumpus|yes it was also my own dumb fault for not noticing it, on the other hand that PR changed so much in the format it was easy to miss
 81 2018-04-19 12:46:08	0|sipa|if counting cpu cycles actually more reliable then counting time in benchmarks? i generally lock my cpu to a single frequency to do benchmarks, as noise complicates things otherwise, but i never botheres trying to look at cpu cycles
 82 2018-04-19 12:47:32	0|MarcoFalke|sipa: That was my though. Only difference would be when cpu waits on io?
 83 2018-04-19 12:48:00	0|sipa|MarcoFalke: waiting on IO does not directly reduce clock rate
 84 2018-04-19 12:48:43	0|sipa|it could cause a switch to a different process though (but then cpu time is not counted anymore, while cycles are!)
 85 2018-04-19 12:49:21	0|MarcoFalke|oh, cycles are still counted?
 86 2018-04-19 12:49:46	0|MarcoFalke|In which case it would be identical to clock
 87 2018-04-19 12:49:51	0|sipa|yes, the cycle counter is per cpu thread
 88 2018-04-19 12:50:19	0|sipa|which clock are we using?
 89 2018-04-19 12:50:26	0|sipa|cpu time or wall time?
 90 2018-04-19 12:50:30	0|MarcoFalke|Yeah, I think BlueMatt told me something that the clock might be using cycles internally
 91 2018-04-19 12:51:01	0|MarcoFalke|std::chrono::steady_clock mostly
 92 2018-04-19 12:51:37	0|MarcoFalke|fallback to std::chrono::high_resolution_clock
 93 2018-04-19 12:51:58	0|MarcoFalke|other way round, sorry
 94 2018-04-19 12:52:55	0|sipa|yup, sorry  those also keep ticking if a process if not executing
 95 2018-04-19 12:53:57	0|sipa|though it's unclear what those clocks really dl
 96 2018-04-19 12:54:11	0|wumpus|it's one big stack of abstractions
 97 2018-04-19 12:54:12	0|sipa|they may use system calls
 98 2018-04-19 12:54:57	0|sipa|which are completely inappropriate if you want to measure very short running pieces of code (sub microsecond)
 99 2018-04-19 12:55:07	0|wumpus|at least cpu cycles is a clear, transparant metric, the only problem is that it's not available on all architectures, and on e.g. ARM it needs system calls to measure :-/
100 2018-04-19 12:55:47	0|MarcoFalke|sipa: I think that is why we loop a bit before taking the clock
101 2018-04-19 12:56:26	0|MarcoFalke|in fact the iterations are hardcoded
102 2018-04-19 12:56:45	0|sipa|that may be historical
103 2018-04-19 12:57:26	0|sipa|the benchmarks used to be entirely self-measuring (aiming to run for 1s)
104 2018-04-19 12:58:18	0|bitcoin-git|13bitcoin/06master 142c084a6 15Thomas Snider: net: Minor accumulated cleanups
105 2018-04-19 12:58:18	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/39cf27faf324...c19986940869
106 2018-04-19 12:58:19	0|bitcoin-git|13bitcoin/06master 14c199869 15Wladimir J. van der Laan: Merge #12855: net: Minor accumulated cleanups...
107 2018-04-19 12:59:03	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12855: net: Minor accumulated cleanups (06master...06tjps_misc_cleans) 02https://github.com/bitcoin/bitcoin/pull/12855
108 2018-04-19 13:02:22	0|wumpus|but yes I was overreacting, sorry MarcoFalke
109 2018-04-19 13:04:20	0|MarcoFalke|wumpus: no worries :)
110 2018-04-19 13:35:27	0|promag|I would really appreciate some reviews in #13017, ty
111 2018-04-19 13:35:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/13017 | Add wallets management functions by promag · Pull Request #13017 · bitcoin/bitcoin · GitHub
112 2018-04-19 13:35:52	0|promag|simple stuff
113 2018-04-19 13:52:09	0|bitcoin-git|[13bitcoin] 15promag opened pull request #13028: Make vpwallets usage thread safe (06master...062018-04-cs_wallets) 02https://github.com/bitcoin/bitcoin/pull/13028
114 2018-04-19 14:26:21	0|BlueMatt|sipa: the reason the iteration count was hardcoded is cause the time measured changed a shitload depending on iteration counts
115 2018-04-19 14:26:44	0|BlueMatt|so hardcoding was easier to get more stable results than running it 20 times until you had a bunch of results for the iteration count you wanted
116 2018-04-19 14:27:23	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #13029: Interpret absense of prune= as prune=1 if there are pruned blocks (06master...062018/04/implicit_prune) 02https://github.com/bitcoin/bitcoin/pull/13029
117 2018-04-19 15:21:08	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #13030: [bugfix] [wallet] Fix zapwallettxes/multiwallet interaction. (06master...06fix_zapwallet_multiwallet_interaction) 02https://github.com/bitcoin/bitcoin/pull/13030
118 2018-04-19 17:28:24	0|jnewbery|wumpus: I think #13024 can go on the high priority for review. It's blocking walletload, which a few people said they wanted for V0.17 in the last weekly meeting.
119 2018-04-19 17:28:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/13024 | test: Add rpcauth pair that generated by rpcauth by ken2812221 · Pull Request #13024 · bitcoin/bitcoin · GitHub
120 2018-04-19 17:28:31	0|jnewbery|sorry, not 13024
121 2018-04-19 17:28:40	0|jnewbery|sorry, not #13017
122 2018-04-19 17:28:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/13017 | Add wallets management functions by promag · Pull Request #13017 · bitcoin/bitcoin · GitHub
123 2018-04-19 17:28:56	0|jnewbery|That one ^^ 13017
124 2018-04-19 18:10:02	0|BlueMatt|I'll probably miss the meeting, but, hey, I got through 3/4 of the high-priority PRs, even acked 2, and left blocking comments on the 3rd....how did *you* do this week?
125 2018-04-19 18:10:39	0|BlueMatt|someone should repeat that when meeting time comes ^ :p
126 2018-04-19 18:13:13	0|kanzure|will do
127 2018-04-19 18:34:27	0|bitcoin-git|13bitcoin/06master 14defffb3 15João Barbosa: trivial: Improve include comment in src/interfaces/wallet.h
128 2018-04-19 18:34:27	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c19986940869...9b3a67eb0861
129 2018-04-19 18:34:28	0|bitcoin-git|13bitcoin/06master 149b3a67e 15MarcoFalke: Merge #13026: Fix include comment in src/interfaces/wallet.h...
130 2018-04-19 18:35:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13026: Fix include comment in src/interfaces/wallet.h (06master...062018-04-fixincludecomment) 02https://github.com/bitcoin/bitcoin/pull/13026
131 2018-04-19 18:40:01	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9b3a67eb0861...0a8b7b4b33c9
132 2018-04-19 18:40:02	0|bitcoin-git|13bitcoin/06master 1495749a5 15Suhas Daftuar: Separate NULLDUMMY enforcement from SEGWIT enforcement...
133 2018-04-19 18:40:02	0|bitcoin-git|13bitcoin/06master 14ce65018 15Suhas Daftuar: Use P2SH consensus rules for all blocks...
134 2018-04-19 18:40:03	0|bitcoin-git|13bitcoin/06master 145c31b20 15Suhas Daftuar: [qa] Remove some pre-activation segwit tests...
135 2018-04-19 18:40:24	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11739: Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis (06master...062017-09-p2sh-segwit-from-genesis) 02https://github.com/bitcoin/bitcoin/pull/11739
136 2018-04-19 18:46:06	0|wumpus|jnewbery: 13017 already has lots of (ut)ACKs, I'm not sure it makes sense to add it to high priority for review anymore
137 2018-04-19 18:50:50	0|promag|yap, just merge it instead :)
138 2018-04-19 18:51:07	0|luke-jr|(not going to be on time for the meeting, but will try to join as soon as I can)
139 2018-04-19 18:59:48	0|lightningbot|Meeting started Thu Apr 19 19:00:09 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
140 2018-04-19 18:59:48	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
141 2018-04-19 18:59:48	0|wumpus|#startmeeting
142 2018-04-19 18:59:53	0|sipa|ohai
143 2018-04-19 19:00:00	0|jonasschnelli|hi
144 2018-04-19 19:00:03	0|promag|hi
145 2018-04-19 19:00:08	0|achow101|hi
146 2018-04-19 19:00:13	0|jnewbery|hi
147 2018-04-19 19:00:16	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
148 2018-04-19 19:00:17	0|kanzure|hi.
149 2018-04-19 19:00:19	0|instagibbs|hi
150 2018-04-19 19:00:20	0|aj|'lo
151 2018-04-19 19:00:28	0|cfields|hi
152 2018-04-19 19:01:02	0|jonasschnelli|;;seen gmaxwell
153 2018-04-19 19:01:03	0|gribble|gmaxwell was last seen in #bitcoin-core-dev 5 weeks, 0 days, 1 hour, and 59 seconds ago: <gmaxwell> it's not like you pay lower fees due to it.
154 2018-04-19 19:01:13	0|meshcollider|hi
155 2018-04-19 19:01:15	0|wumpus|any proposed topics?
156 2018-04-19 19:01:28	0|jonasschnelli|I'd like to touch the light client mode design
157 2018-04-19 19:01:40	0|wumpus|ok
158 2018-04-19 19:01:42	0|promag|check high priority review first?
159 2018-04-19 19:01:46	0|kanzure|11:10 < BlueMatt> I'll probably miss the meeting, but, hey, I got through 3/4 of the high-priority PRs, even acked 2, and left blocking comments on the 3rd....how did *you* do this week?
160 2018-04-19 19:01:47	0|jonasschnelli|ack
161 2018-04-19 19:02:00	0|jonasschnelli|we can't view jimpos txindex PR
162 2018-04-19 19:02:00	0|wumpus|promag: yes, that's always the first topic
163 2018-04-19 19:02:09	0|jonasschnelli|github issue... can we reopen the PR in a new #?
164 2018-04-19 19:02:11	0|sipa|I'd like #13002 on the high-priority list
165 2018-04-19 19:02:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/13002 | Do not treat bare multisig outputs as IsMine unless watched by sipa · Pull Request #13002 · bitcoin/bitcoin · GitHub
166 2018-04-19 19:02:25	0|wumpus|#topic high priority for review
167 2018-04-19 19:02:28	0|wumpus|https://github.com/bitcoin/bitcoin/projects/8
168 2018-04-19 19:02:38	0|Murch|hi
169 2018-04-19 19:02:38	0|sipa|Also, I can't open #11857
170 2018-04-19 19:02:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
171 2018-04-19 19:02:58	0|jonasschnelli|added 13002
172 2018-04-19 19:03:00	0|sipa|Do we at some point just close the PR and open a new one, to flush all historical discussion?
173 2018-04-19 19:03:09	0|jonasschnelli|sipa: yes
174 2018-04-19 19:03:13	0|sipa|(assuming that's the reason for the sad unicorn)
175 2018-04-19 19:03:19	0|jonasschnelli|jimpo should do it though...
176 2018-04-19 19:03:24	0|sipa|yes
177 2018-04-19 19:03:26	0|kanzure|has someone reported the unicorn to support@github.com
178 2018-04-19 19:03:27	0|jonasschnelli|I could not get hold of him in. the last days
179 2018-04-19 19:03:32	0|achow101|maybe telling github would help...
180 2018-04-19 19:03:35	0|jonasschnelli|kanzure: please do
181 2018-04-19 19:03:50	0|sipa|probably better if a repo owner does so
182 2018-04-19 19:03:56	0|sipa|i'll send a mail
183 2018-04-19 19:03:59	0|jonasschnelli|I doubt it would help in a resonable timeframe
184 2018-04-19 19:03:59	0|meshcollider|I don't get the unicorn, I can see it fine
185 2018-04-19 19:04:06	0|jonasschnelli|it's wired
186 2018-04-19 19:04:11	0|promag|me to, but in incognito
187 2018-04-19 19:04:15	0|instagibbs|kanzure, i did
188 2018-04-19 19:04:17	0|wumpus|I see the unicorn
189 2018-04-19 19:04:18	0|jonasschnelli|I can't. But i can in mobile view
190 2018-04-19 19:04:29	0|instagibbs|incognito works reliably for me
191 2018-04-19 19:04:30	0|jnewbery|instagibbs reported it
192 2018-04-19 19:04:32	0|kanzure|instagibbs: thanks. i'll refrain.
193 2018-04-19 19:04:48	0|sipa|instagibbs: when?
194 2018-04-19 19:04:52	0|instagibbs|couple days ago
195 2018-04-19 19:04:56	0|sipa|any response?
196 2018-04-19 19:04:59	0|instagibbs|no
197 2018-04-19 19:05:07	0|achow101|I've reported it just now
198 2018-04-19 19:05:18	0|achow101|also works in private browsing (firefox)
199 2018-04-19 19:05:59	0|jonasschnelli|logged out state works
200 2018-04-19 19:06:12	0|jonasschnelli|however, jimpo should just open a new PR
201 2018-04-19 19:07:16	0|jamesob|I can view it in lynx just fine
202 2018-04-19 19:07:18	0|sipa|suggested tiny topic: cyclic dependency
203 2018-04-19 19:07:25	0|jonasschnelli|hah jamesob
204 2018-04-19 19:07:29	0|jamesob|;)
205 2018-04-19 19:08:06	0|wumpus|#topic cyclic dependency
206 2018-04-19 19:08:44	0|sipa|i was wondering if we should have a policy against the type of cyclic dependency where the .cpp files include eachother's .h files (but not .h files include eachother)
207 2018-04-19 19:09:14	0|sipa|that's not a cyclic dependency for the compiler, but it does mean those two modules can't really be used independently and is generally a sign of bad separation
208 2018-04-19 19:09:14	0|wumpus|do we have that problem?
209 2018-04-19 19:09:16	0|cfields|sipa: example?
210 2018-04-19 19:09:16	0|kanzure|do we have many of that
211 2018-04-19 19:09:23	0|sipa|there are a few open PRs that introduce them
212 2018-04-19 19:09:53	0|wumpus|I do agree cyclic dependency should be avoided in general
213 2018-04-19 19:09:58	0|sipa|so i wanted to bring it up here to see if that should be a PR merging blocker
214 2018-04-19 19:10:07	0|sipa|or just a "try to fix it up afterwards if introduced"
215 2018-04-19 19:10:24	0|sipa|i'm fine with either
216 2018-04-19 19:10:45	0|cfields|indeed sounds like likely bad design that should at least be justified in the PR
217 2018-04-19 19:10:58	0|sdaftuar|cfields: +1
218 2018-04-19 19:10:59	0|jonasschnelli|Yes. And maybe mention it in the developer guidelines?
219 2018-04-19 19:11:01	0|meshcollider|Sounds like it'd be a painful thing to fix up afterwards in some cases
220 2018-04-19 19:11:01	0|wumpus|right, might make sense to discuss this in the PR
221 2018-04-19 19:11:03	0|aj|seems good to fix it before merge, but not sure it should be added as a lint check or similar
222 2018-04-19 19:11:05	0|sdaftuar|i can imagine that in some contexts we'd merge anyway
223 2018-04-19 19:11:32	0|sdaftuar|but might be blocking in others
224 2018-04-19 19:11:40	0|meshcollider|^
225 2018-04-19 19:11:48	0|sipa|#12954 introduces one for example
226 2018-04-19 19:11:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/12954 | util: Refactor logging code into a global object by jimpo · Pull Request #12954 · bitcoin/bitcoin · GitHub
227 2018-04-19 19:12:14	0|wumpus|for a refactor it should definitely be avoided
228 2018-04-19 19:12:22	0|wumpus|refactoring is supposed to make the code better
229 2018-04-19 19:12:28	0|wumpus|not introduce further bad design
230 2018-04-19 19:12:36	0|sdaftuar|that might be an example of an improvement that just doens't go far enough though?
231 2018-04-19 19:12:43	0|sipa|well one way of looking at it is that the current util.cpp there has two subcomponents that already have a cyclic dependency
232 2018-04-19 19:12:54	0|sipa|within the same .cpp file
233 2018-04-19 19:13:05	0|sipa|and forcing people to fix it before they can separate it is maybe counterproductive
234 2018-04-19 19:13:13	0|sipa|or not ;)
235 2018-04-19 19:13:14	0|wumpus|maybe...
236 2018-04-19 19:13:55	0|sipa|enough on the topic i guess
237 2018-04-19 19:14:05	0|jcohen|one "quick" solution to avoiding that circular dep would be to jam it all into a single file - which i think would be even less desireable
238 2018-04-19 19:14:17	0|wumpus|it is already in a single file
239 2018-04-19 19:14:20	0|jcohen|the alternative would be to split util up even further, which would lengthen the diff
240 2018-04-19 19:14:44	0|sipa|this is just an example, it's relatively easy to fix in this case
241 2018-04-19 19:14:45	0|cfields|sipa: right. Since the point of this one is to break up a big blob anyway, requiring it to solve the circular issue in one go would be pretty burdensome. But if it's moving in the right direction, imo maintaining the status quo is ok.
242 2018-04-19 19:15:01	0|cfields|we could go back to main.cpp :p
243 2018-04-19 19:15:10	0|sipa|cat *.cpp | gcc -
244 2018-04-19 19:15:11	0|wumpus|cfields: true...
245 2018-04-19 19:15:18	0|achow101|"just put everything into one big file and call it main.cpp"
246 2018-04-19 19:15:30	0|wumpus|I don't think I feel strong enough about this one to put it in the guidelines
247 2018-04-19 19:15:37	0|jtimon|well, perhaps breaking util as needed first makes sense
248 2018-04-19 19:15:48	0|wumpus|though commenting on it where relevant is a good idea
249 2018-04-19 19:15:52	0|sipa|sgtm
250 2018-04-19 19:16:23	0|wumpus|if there's an obvious solution to avoid it that's better, but we cannot enumerate every single software design compromise
251 2018-04-19 19:16:57	0|wumpus|#topic light client mode design (jonasschnelli)
252 2018-04-19 19:17:17	0|aj|#13021 does the "break util as needed first" by the looks - logging.cpp includes util.h, util.h includes logging.h
253 2018-04-19 19:17:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/13021 | MOVEONLY: Move logging code from util.{h,cpp} to new files. by jimpo · Pull Request #13021 · bitcoin/bitcoin · GitHub
254 2018-04-19 19:17:20	0|jonasschnelli|I'd like to get some feedback about the light client mode... particular the "requestblock" design
255 2018-04-19 19:17:28	0|jonasschnelli|#10794
256 2018-04-19 19:17:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
257 2018-04-19 19:17:37	0|jonasschnelli|if that is something we should follow or drop
258 2018-04-19 19:18:04	0|jonasschnelli|I know the use-cases with 10794 are limited, but a stepping stone towards hybrid and BIP158 light validation
259 2018-04-19 19:18:39	0|sipa|jonasschnelli: will review
260 2018-04-19 19:18:57	0|jonasschnelli|maybe first check for a concept ACK/NACK
261 2018-04-19 19:19:06	0|jtimon|aj: yeah, and it seems moveonly, so perhaps just rebasing 12954 on top of 13021 solves the issue in this case? sipa
262 2018-04-19 19:20:01	0|sipa|jonasschnelli: yes, makes sense - it's a bit too much to look at right now in the meeting though, i think
263 2018-04-19 19:20:08	0|jonasschnelli|sure...
264 2018-04-19 19:20:36	0|jonasschnelli|I'm only interested to know if the concept make sense for you guys
265 2018-04-19 19:20:52	0|jonasschnelli|(of having a light client mode)
266 2018-04-19 19:20:58	0|wumpus|they have been open for a long time, probably should et around to at least concept-acking them
267 2018-04-19 19:21:05	0|sipa|yes
268 2018-04-19 19:21:23	0|jonasschnelli|Great. Thanks
269 2018-04-19 19:21:25	0|sipa|jonasschnelli: oh, the idea of having a client mode - that makes absolutely sense to me
270 2018-04-19 19:21:31	0|sipa|but it heavily depends on how and what :)
271 2018-04-19 19:21:42	0|meshcollider|Having a light client mode is definitely a concept ACK for me
272 2018-04-19 19:21:50	0|LukeJr|jonasschnelli: only as a temporary stage
273 2018-04-19 19:21:57	0|sipa|LukeJr: how so?
274 2018-04-19 19:21:59	0|jonasschnelli|right... I wasn't sure if the PR is the right place to discuss that or if we want to do it in a meeting
275 2018-04-19 19:22:21	0|LukeJr|sipa: it should always be building up to a full node in the bg
276 2018-04-19 19:22:51	0|sipa|LukeJr: i disagree - it's a perfectly valid usecase to have one full node you run yourself, and then have multiple client nodes connect exclusively to it
277 2018-04-19 19:22:54	0|LukeJr|(even if that bg process is paused for a time)
278 2018-04-19 19:23:14	0|LukeJr|sipa: hmm
279 2018-04-19 19:23:21	0|cfields|jonasschnelli: I realize this is really unhelpful feedback, but I find the current download logic nearly impossible to follow as-is. I remember giving up on review of this last time for that reason. Imo it's due for a bit of a cleanup/encapsulation before piling more on :(
280 2018-04-19 19:23:51	0|sipa|LukeJr: but lightweight upgrading to full in the background is also an very good usecase, imho
281 2018-04-19 19:23:53	0|cfields|(feel free to ignore that, maybe it's just my issue reading the code)
282 2018-04-19 19:24:21	0|sdaftuar|cfields: you are not the only person who finds the download logic confusing :)
283 2018-04-19 19:24:40	0|sipa|i believe those who (helped) write it agree :)
284 2018-04-19 19:24:50	0|jonasschnelli|heh. Yes. The open PR is not the first try to make this with a possible very small impact on the code...
285 2018-04-19 19:25:04	0|sipa|jonasschnelli: thanks for stickin with it, though
286 2018-04-19 19:25:34	0|cfields|yes, I was hesitant to mention that because I didn't want to de-motivate at all.
287 2018-04-19 19:25:38	0|LukeJr|sipa: as soon as the wallet is split, your use case just works
288 2018-04-19 19:26:09	0|sipa|LukeJr: this is how i imagine the wallet being split :)
289 2018-04-19 19:26:52	0|jamesob|*cough* #10973 *cough*
290 2018-04-19 19:26:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/10973 | Refactor: separate wallet from node by ryanofsky · Pull Request #10973 · bitcoin/bitcoin · GitHub
291 2018-04-19 19:26:57	0|jonasschnelli|It's still unclear though how fee estimations and mempool checks would be done "in that way"
292 2018-04-19 19:27:24	0|sipa|jamesob: that's modularizing the code better, which is independently useful
293 2018-04-19 19:28:46	0|sipa|i don't think the goal should be separating the wallet from the node into different processes, and then inventing a protocol between the two... instead of just making the wallet run as a light client
294 2018-04-19 19:29:19	0|jamesob|the two sound very similar to me
295 2018-04-19 19:29:29	0|LukeJr|I don't agree. There's no reason the wallet and node should be in the same process.
296 2018-04-19 19:30:28	0|jonasschnelli|sipa: I agree. For me its just unclear how to transport fee estimations and mempool checks between light client and the fullnode.
297 2018-04-19 19:30:38	0|wumpus|LukeJr: that's not what sipa is saying, in his case the node and wallet would also be in different processes, but without custom protocol
298 2018-04-19 19:30:56	0|sipa|jamesob: the advantage of using P2P as communication between node and wallet (which is what you get if you see wallets as just lightweight nodes) is that it actually modularizing things: you can run _any_ wallet software or _any_ node software
299 2018-04-19 19:31:08	0|jamesob|wumpus sipa: but then using what protocol? a more fleshed out rpc interface?
300 2018-04-19 19:31:15	0|sipa|jamesob: P2P
301 2018-04-19 19:31:16	0|instagibbs|p2p messages
302 2018-04-19 19:31:28	0|instagibbs|with whitelisted fee estimation type messages, i assume
303 2018-04-19 19:31:34	0|wumpus|right
304 2018-04-19 19:31:43	0|jonasschnelli|instagibbs: but not before we have BIP150/151
305 2018-04-19 19:31:57	0|wumpus|I think for localhost it's fine without?
306 2018-04-19 19:32:00	0|jonasschnelli|I don't want MITMled fees
307 2018-04-19 19:32:02	0|jonasschnelli|yes. sure
308 2018-04-19 19:32:10	0|sipa|oh, short topic: update on private authentication protocols
309 2018-04-19 19:32:19	0|wumpus|but yes, in general that's correct
310 2018-04-19 19:32:34	0|jnewbery|I don't think doing process separation with IPC precludes later doing a p2p-based wallet
311 2018-04-19 19:32:36	0|jamesob|sipa: thanks for the explanation; will noodle on that
312 2018-04-19 19:32:54	0|jnewbery|p2p-based wallet seems like a very large project
313 2018-04-19 19:32:55	0|sipa|jnewbery: i agree, but i think it's a bit overkill
314 2018-04-19 19:33:03	0|sipa|jnewbery: however, i don't think that's a choice that needs to be made
315 2018-04-19 19:33:21	0|jonasschnelli|jnewbery: we are not too far away from a p2p based wallet IMO
316 2018-04-19 19:33:24	0|sipa|encapsulating the communication between node and wallet is an objective improvement to the code
317 2018-04-19 19:33:44	0|sipa|even if it does not lead to also a process separation along that interface
318 2018-04-19 19:34:16	0|jnewbery|jonasschnelli: really? Maybe I overestimate the difficulty, but it seems like we'd need a lot of new logic in the wallet to understand p2p
319 2018-04-19 19:34:26	0|sipa|jnewbery: you misunderstand!
320 2018-04-19 19:34:34	0|sipa|jnewbery: it would reuse all the existing full node code
321 2018-04-19 19:34:38	0|sipa|and p2p implementation
322 2018-04-19 19:34:44	0|sipa|just don't do validation
323 2018-04-19 19:34:45	0|instagibbs|turn off full validation, ofc
324 2018-04-19 19:34:46	0|ryanofsky|just catching up, but yeah, i think two approaches are not exclusive, and work done to support ipc will be useful anyway for making wallet more independent and better able to do async p2p stuff
325 2018-04-19 19:34:48	0|jonasschnelli|jnewbery: it needs BIP158 light client mode (or fullblock), fee and mempool checks. Done
326 2018-04-19 19:35:08	0|sipa|ryanofsky: yes, fully agree
327 2018-04-19 19:35:29	0|jonasschnelli|You just start two instances of Core. One as a full node, one with disabled validation pointing to the full node
328 2018-04-19 19:36:37	0|jonasschnelli|--> <sipa>	oh, short topic: update on private authentication protocols
329 2018-04-19 19:36:37	0|LukeJr|does it simplify or complicate the internal code? (ignoring the present level of complexity in itself)
330 2018-04-19 19:36:38	0|jnewbery|ok, I understand. How much work is it to make core work in --disablevalidation mode?
331 2018-04-19 19:36:50	0|sipa|jnewbery: that's the current topic :)
332 2018-04-19 19:37:07	0|jonasschnelli|jnewbery: 10794
333 2018-04-19 19:37:10	0|jonasschnelli|(does it)
334 2018-04-19 19:37:11	0|jnewbery|ok, I'll shut up and read the PR
335 2018-04-19 19:37:41	0|jonasschnelli|although 10794 leads out the wallet
336 2018-04-19 19:37:49	0|jonasschnelli|(to make it reviewable)
337 2018-04-19 19:37:59	0|jonasschnelli|*lefts out
338 2018-04-19 19:38:17	0|wumpus|#topic update on private authentication protocols (sipa)
339 2018-04-19 19:39:03	0|sipa|so, as some know gmaxwell and i have been thinking about authentication protocols that have better privacy than bip150
340 2018-04-19 19:39:44	0|jonasschnelli|privacy in the sense of fingerprinting?
341 2018-04-19 19:39:47	0|sipa|yes
342 2018-04-19 19:40:01	0|sipa|the goal is to have a design where one node has 1 or more private keys, and the other node has 1 or more public keys
343 2018-04-19 19:40:18	0|sipa|and the second node learns whether one of the other node's private keys matches one of your public keys
344 2018-04-19 19:40:21	0|sipa|but _nothing_ else
345 2018-04-19 19:40:35	0|sipa|the node with the private keys does not even learn if authentication was succesful
346 2018-04-19 19:40:47	0|sipa|or doesn't learn which keys it was being queried for
347 2018-04-19 19:41:04	0|jonasschnelli|the use case is then wide deploey authentication sheme rather then the more client-server-ish approach?
348 2018-04-19 19:41:20	0|sipa|it's still client-server
349 2018-04-19 19:41:39	0|sipa|the cool thing about this is that you can always run the authentication protocol
350 2018-04-19 19:41:41	0|LukeJr|sounds hard to give an "authentication failiure" error?
351 2018-04-19 19:42:12	0|sipa|LukeJr: the idea is that most of our connections are unauthentication anyway (and should be)... so whatever privileges you give to authenticated nodes, you just don't give if auth fails
352 2018-04-19 19:42:23	0|sipa|this has a very cool property
353 2018-04-19 19:42:31	0|sipa|you can _always_ run this authentication protocol
354 2018-04-19 19:42:38	0|sipa|even if you don't care who the other party is
355 2018-04-19 19:42:43	0|jonasschnelli|sipa: but, if you have node A and node B's pubkeys and you want connect to A, how can you be sure you'r not connecting to B?
356 2018-04-19 19:42:49	0|LukeJr|sipa: but if the authenticating node doesn't know if it failed, then it doesn't know if it has an authentication connection it expects
357 2018-04-19 19:43:15	0|sipa|LukeJr: it can run the same protocol in the other direction to find out
358 2018-04-19 19:43:21	0|LukeJr|hmm
359 2018-04-19 19:43:33	0|sipa|jonasschnelli: you just query for who you want the other party to be
360 2018-04-19 19:43:37	0|phantomcircuit|or just ask for something that requires authentication
361 2018-04-19 19:44:19	0|sipa|the cool thing is that if you always run the authentication protocol, but if you're not interested in authentication do it with just a randomly generated pubkey, a MitM can't find out what you're doing
362 2018-04-19 19:44:27	0|sipa|they have to assume you're trying to authenticate
363 2018-04-19 19:44:41	0|sipa|anyway, turns out... this is difficult
364 2018-04-19 19:44:43	0|cfields|sipa: i'm not sure if this has evolved from when we discussed last... does your peer learn how many pubkeys you'd accept?
365 2018-04-19 19:44:58	0|sipa|cfields: yes, but you can stuff your request with a number of random ones
366 2018-04-19 19:45:06	0|cfields|right, ok
367 2018-04-19 19:45:08	0|sipa|just pad to 256 keys or whatever, always
368 2018-04-19 19:45:30	0|instagibbs|so, did you fix it? :)
369 2018-04-19 19:45:33	0|jonasschnelli|sounds interesting.. are there written specs already?
370 2018-04-19 19:45:38	0|sipa|we have a protocol that works with 1 privkey and 1 pubkey - which means you need to run in many times sometimes which doesn't lead to great fingerprinting properties
371 2018-04-19 19:45:48	0|sipa|and i'm talking to some people to extend it :)
372 2018-04-19 19:46:24	0|jonasschnelli|Great. Thanks!
373 2018-04-19 19:46:28	0|sipa|jonasschnelli: https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
374 2018-04-19 19:46:36	0|sipa|note that that protocol linked to is broken
375 2018-04-19 19:46:54	0|sipa|but it does explain the rationale pretty well, i think
376 2018-04-19 19:47:16	0|sipa|end topic
377 2018-04-19 19:47:29	0|jonasschnelli|I guess this protocol would require more cryptoanalysis then the exiting BIP150
378 2018-04-19 19:47:47	0|sipa|jonasschnelli: that's ok, i'm talking to dan boneh about it
379 2018-04-19 19:48:06	0|jonasschnelli|Good!
380 2018-04-19 19:48:29	0|meshcollider|Dan is the solution to all crypto problems
381 2018-04-19 19:48:35	0|jonasschnelli|heh
382 2018-04-19 19:48:56	0|wumpus|it'd be good as a future successor to BIP150 - though I guess this research shouldn't discourage anyone from implementing BIP150 and having something working on more short term
383 2018-04-19 19:49:04	0|sipa|right
384 2018-04-19 19:49:21	0|wumpus|(maybe that's obvious, but just to be clear)
385 2018-04-19 19:49:22	0|jonasschnelli|Implementing BIP151/150 is still hold back due to the network refactor, right?
386 2018-04-19 19:49:42	0|jonasschnelli|If not, I can continue on BIP150
387 2018-04-19 19:49:47	0|jonasschnelli|sry. 1541
388 2018-04-19 19:49:48	0|jonasschnelli|sry. 151
389 2018-04-19 19:49:49	0|cfields|sipa: I'm still a bit confused as to the use-case. Is the intent to be able to explicitly find a known peer, or more generally to build up a list of tofu-ish nodes that aren't known to misbehave, and look for them first when creating outbound connections?
390 2018-04-19 19:50:05	0|jnewbery|cfields: what's the state of network refactor? Any PRs awaiting review?
391 2018-04-19 19:50:05	0|sipa|cfields: you can't do TOFU, you don't learn who you're connecting to
392 2018-04-19 19:50:28	0|sipa|cfields: the whole point is avoiding having discoverable identities for things that should be identityless
393 2018-04-19 19:50:44	0|sipa|but sometimes you have a node you trust already (due to external reasons, for example you run it yourself)
394 2018-04-19 19:50:59	0|sipa|in which case you'd configure an addnode with a known pubkey or so
395 2018-04-19 19:51:14	0|cfields|sipa: got it, thanks.
396 2018-04-19 19:51:29	0|cfields|jnewbery: #11457 still, looks like it needs rebase again
397 2018-04-19 19:51:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/11457 | Introduce BanMan by theuni · Pull Request #11457 · bitcoin/bitcoin · GitHub
398 2018-04-19 19:51:32	0|sipa|yes, BIP150 can continue independently
399 2018-04-19 19:51:34	0|cfields|doing now, thanks for the reminder
400 2018-04-19 19:51:36	0|sipa|eh, BIP151
401 2018-04-19 19:51:39	0|Murch|cfields: In the case that you for example want to connect with a thin client to your own node, the only valid key you query for is your home node's. If you want to defend against Sybil, you may query a list of known friends and accept any of them. If you just want to scare off a MITM, you query for random keys.
402 2018-04-19 19:52:06	0|sipa|this is just a replacement for the authentication part; it needs an existing encrypted connection to run over anyway
403 2018-04-19 19:52:52	0|LukeJr|how does one authenticate the encryption key?
404 2018-04-19 19:52:58	0|sipa|you don't
405 2018-04-19 19:53:17	0|jonasschnelli|bip151 does not protect from MITM
406 2018-04-19 19:53:18	0|sipa|encryption is done with ephemeral keys, and is completely unauthenticated
407 2018-04-19 19:53:24	0|sipa|it does not protect against MitM
408 2018-04-19 19:53:29	0|jonasschnelli|Only from passible observing and undetectable interception
409 2018-04-19 19:53:34	0|jonasschnelli|*passive
410 2018-04-19 19:53:49	0|sipa|but then you run an authentication protocol which can determine if the party you are talking to (possibly the MitM) is who you think it is
411 2018-04-19 19:54:14	0|sipa|anyway, enough on the topic
412 2018-04-19 19:54:22	0|sipa|just wanted to give an update that there are some cool ideas
413 2018-04-19 19:54:28	0|wumpus|yes, thanks!
414 2018-04-19 19:54:38	0|jonasschnelli|thanks sipa for working on this!
415 2018-04-19 19:55:00	0|wumpus|unless someone has a very quick last-minutet topic I think that was the last topic for today
416 2018-04-19 19:55:40	0|wumpus|clear :)
417 2018-04-19 19:55:41	0|wumpus|#endmeeting
418 2018-04-19 19:55:42	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.log.html
419 2018-04-19 19:55:42	0|lightningbot|Meeting ended Thu Apr 19 19:56:03 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
420 2018-04-19 19:55:42	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.html
421 2018-04-19 19:55:42	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-04-19-19.00.txt
422 2018-04-19 19:57:02	0|promag|jtimon: sorry, forgot about #10757
423 2018-04-19 19:57:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
424 2018-04-19 20:04:15	0|phantomcircuit|sipa, separating encryption and authentication like that has the potential for an obvious mistake
425 2018-04-19 20:04:43	0|phantomcircuit|mitm encryption and then fail to authenticate the shared secret used for encryption
426 2018-04-19 20:21:15	0|achow101|question about wallet hd upgrade path (#12560): is it preferable to warn that a new backup is needed for -upgradewallet or just use a new option entirely?
427 2018-04-19 20:21:18	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
428 2018-04-19 20:33:12	0|sipa|phantomcircuit: then you just have an unauthenticated connection that's still safe from passive attackers
429 2018-04-19 21:29:50	0|phantomcircuit|sipa, yeah but you get what im saying im sure
430 2018-04-19 21:34:50	0|jimpo|Sorry, I missed meeting. So I should open a new PR for #11857? It also loads for me, but I can do that if people want...
431 2018-04-19 21:34:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/11857 | Build tx index in parallel with validation by jimpo · Pull Request #11857 · bitcoin/bitcoin · GitHub
432 2018-04-19 21:37:55	0|jimpo|Also, I'd really like to get #13021 in before I have to rebase it again
433 2018-04-19 21:37:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/13021 | MOVEONLY: Move logging code from util.{h,cpp} to new files. by jimpo · Pull Request #13021 · bitcoin/bitcoin · GitHub
434 2018-04-19 22:46:37	0|bitcoin-git|[13bitcoin] 15sipsorcery opened pull request #13031: Fix for utiltime to compile with msvc. (06master...06msvc_gmtime) 02https://github.com/bitcoin/bitcoin/pull/13031
435 2018-04-19 23:39:41	0|achow101|BlueMatt: what's your idea for detecting old keypool keys?
436 2018-04-19 23:54:56	0|bitcoin-git|[13bitcoin] 15kristapsk opened pull request #13032: Output values for "min relay fee not met" error (06master...06min-relay-fee-not-met-debug) 02https://github.com/bitcoin/bitcoin/pull/13032