--- Day changed Wed Oct 23 2019 00:11 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 245 seconds] 01:15 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews 01:34 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 01:39 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 01:52 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds] 01:52 -!- jonatack [~jon@213.152.161.35] has joined #bitcoin-core-pr-reviews 03:11 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.4 - https://znc.in] 03:12 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 03:35 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 03:40 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds] 05:22 -!- jonatack [~jon@213.152.161.35] has quit [Ping timeout: 268 seconds] 05:34 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has joined #bitcoin-core-pr-reviews 06:10 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews 06:11 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 06:16 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds] 06:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 07:17 -!- lightlike [~lightlike@2001:16b8:5790:3e00:d138:55e0:afed:8cc1] has joined #bitcoin-core-pr-reviews 07:42 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 07:46 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack] 07:46 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 08:15 -!- devops99 [~textual@vpn.ki-performance.com] has joined #bitcoin-core-pr-reviews 08:18 -!- devops99 [~textual@vpn.ki-performance.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 08:19 -!- ChanServ changed the topic of #bitcoin-core-pr-reviews to: desc Meeting every Wednesday at 17:00 UTC | See https://bitcoincore.reviews/ for details | This channel is logged 08:22 -!- ChanServ changed the topic of #bitcoin-core-pr-reviews to: Meeting every Wednesday at 17:00 UTC | See https://bitcoincore.reviews/ for details | This channel is logged 09:02 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 09:11 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in] 09:12 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 09:22 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews 09:25 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 09:27 -!- diogosergio [~diogoserg@212.36.34.126] has joined #bitcoin-core-pr-reviews 09:30 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Client Quit] 09:32 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 09:41 -!- michaelfolkson [~textual@82-132-235-23.dab.02.net] has joined #bitcoin-core-pr-reviews 09:45 < jnewbery> We'll get started in about 15 minutes 09:47 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews 09:54 -!- ajonas [uid385278@gateway/web/irccloud.com/x-modritlassmlaytb] has joined #bitcoin-core-pr-reviews 09:56 -!- sebastianvstaa [~sebastian@95.211.210.109] has joined #bitcoin-core-pr-reviews 10:00 < emilengler> Hello 10:00 < jnewbery> hi 10:00 < ajonas> Hi 10:00 < amiti> hi 10:00 < michaelfolkson> Hey 10:00 < fjahr> hi 10:01 < jnewbery> Notes and questions: https://bitcoincore.reviews/15934.html 10:01 < ariard> hi 10:01 < lightlike> hello 10:01 < jnewbery> what did everyone think of this week's PR? 10:01 < emzy> Hi 10:01 < jnewbery> (apologies for only posting on Monday. I'll try to post before the weekend for next week) 10:02 < emilengler> jnewbery: I like the idea but I am still skeptical about backwards compatibility 10:02 < emzy> same here. 10:02 < fjahr> good cleanup but also a lot to unpack. I really liked the regression test. 10:02 < emilengler> IMO the user should not really notice anything about this change 10:03 < ariard> I've reviewed it, a lot of back and forth between old and new code to be sure current behaviors are maintained 10:03 < emilengler> Ergo, he should net need to move config files after update 10:03 < kanzure> hi 10:04 < ariard> maybe cd49914 could have been split a bit to ease rw 10:04 < jnewbery> emilengler: right, the author claims that there's no bahaviour change in this PR. I found it quite difficult to verify that 10:04 < lightlike> it looks like a nice cleanup, haven't reviewed every line of code yet, but did some testing. 10:04 < fjahr> emilengler: but that's the point of backwards compatibility 10:04 < fjahr> why do you think they have to move sth? 10:04 < emilengler> jnewbery: I also didn't saw something like a backwards option which moves old config files 10:04 < jnewbery> ariard: that's the middle commit (_Deduplicate settings merge code_)? I did wonder if it would be possible to break it up 10:05 < jonatack> hi 10:05 < emilengler> But in general I like the concept about storing everything in one place 10:05 < ariard> jnewbery: yes this one, cd59914 10:05 < jnewbery> emilengler: there's no moving of files in the PR 10:05 < ajonas> fjahr: that test was so great 10:06 < emilengler> jnewbery: How is backwards compatibility guaranteed then? 10:07 < fjahr> emilengler: are you maybe talking about 15935? 10:07 < jnewbery> emilengler: the author included regression tests to test for compatibility 10:08 < jnewbery> ariard: I see that you've ACKed the PR. Perhaps you can talk about how you went about testing/reviewing? 10:08 < ryanofsky> hey all, just catching up 10:08 < jnewbery> I found that middle commit really hard to review. Looking at the diff wasn't really helpful for me because it was basically a rewrite. 10:08 < jnewbery> hi ryanofsky. Thanks for joining! 10:08 < ryanofsky> backwards compatibility should be guaranteed by the test added previously: https://github.com/bitcoin/bitcoin/pull/15869/files 10:08 < emilengler> ryanofsky: Good to have you here 10:09 < ryanofsky> as long as the hash in that test isn't changing, none of the merge behaviors can change either 10:09 < fjahr> jnewbery: dito on that, I think it could be possible to split it but now it is probably not worth the effort anymore 10:10 < fjahr> I did even cherry-pick the test and ran it against master 10:10 < jnewbery> jonatack / fjahr: you also left review comments (thanks!) did you have any tips on reviewing or testing? 10:12 < jnewbery> Were there any particular parts of the code that anyone found difficult/interesting? 10:13 < ariard> jnewbery: so I went first reviewing new settings.cpp/settings.h files 10:13 < fjahr> Not sure I was really efficient, I just re-read the code many times until I felt I had a good understanding. I felt the tests were really helpful in getting confidence in the code. As I said I cherry-picked the regression test to verify since it was last in the commit history. 10:14 < ariard> then reviewing every old settings merge code like GetArg,GetNetBoolArg and compare against their new versions to be sure effect stay the same 10:15 < jonatack> The test was fun to tweak and did a bit of manual testing. The most time-consuming was reading up on the context and the many idiosyncracies of the current behavior, which ryanofsky already kindly 10:15 < ajonas> I had trouble recreating what JO'Beirne did here https://github.com/bitcoin/bitcoin/pull/15934#pullrequestreview-242727281 10:15 < ariard> and read from ArgsManager to see how ParseParameters and ReadConfigFiles interact, both in master and on merge-settings branch 10:15 < jonatack> explained to me during review of another PR related to this. 10:15 < jnewbery> ariard: yeah, I think that's really the only safe way to do it. Time-consuming but the only way to be sure it is indeed a non-behaviour change. 10:17 < jonatack> I like that a unit test was added instead functional ones. We sometimes see cases where functional tests are written out of ease where unit tests could have been added instead. 10:17 < michaelfolkson> So for that test in #15869 you literally sketched out all the combinations of changing settings in the config and QT and in different orders? And the test checks the resulting behavior is the same pre and post PR? 10:17 < jnewbery> joanatack: I definitely agree with that! 10:17 < michaelfolkson> Some things like having listening switched off if connecting to specific peers I didn't understand the logic behind 10:17 < ryanofsky> michaelfolkson, the test covers all the inputs to argsmanager and all the outputs so there's nothing qt specific 10:18 < jnewbery> Can anyone explain to me what's going on here: https://github.com/bitcoin/bitcoin/pull/15934/commits/4a5e736dc4a22643b4f09181b3d7245727cee876#diff-b372feef646fe8b25a4ad50c22e64b19R74 10:18 < jnewbery> template 10:18 < jnewbery> auto FindKey(Map&& map, Key&& key) -> decltype(&map.at(key)) 10:19 < ryanofsky> "auto Function() -> ReturnType" is a weird way to write "ReturnType Function()" which you are forced to do when the return type depends on the function arguments 10:21 < jnewbery> thanks ryanofsky. Did anyone figure out the && in the function arguments? 10:22 < jonatack> jnewbery: for that i refer to a great comment written once by ryanofsky on when to use double && 10:22 < jnewbery> jonatack: oh yeah? Where's the great comment? 10:23 < jnewbery> So, && in a function argument means the argument is an rvalue reference 10:24 < jonatack> trying to find the original. I copied it into my notes a few months back here https://github.com/jonatack/bitcoin-development/blob/master/notes.txt#L264 10:24 < jnewbery> I found these articles quite useful in explaining rvalue references: https://www.internalpointers.com/post/understanding-meaning-lvalues-and-rvalues-c https://www.internalpointers.com/post/c-rvalue-references-and-move-semantics-beginners 10:26 < jnewbery> if a templated function has rvalue references in its arguments, then we get forwarding references: if an lvalue is provided, then the reference is an lvalue, and if an rvalue is provided, the reference is an rvalue 10:26 < jnewbery> ryanofsky: I think that's right. Correct me if I'm mistaken 10:27 < jnewbery> jonatack: here's the original: https://github.com/bitcoin/bitcoin/pull/15849#pullrequestreview-231748721 10:28 < jonatack> jnewbery: ryanofsky also refers to it in this recent comment in reviewing PR 16202: https://github.com/bitcoin/bitcoin/pull/16202#discussion_r336612138 10:28 < ryanofsky> That's right I think. There are special rules for templates combined with && arguments. But if you want a template argument to accept any argument const or nonconst lvalue or rvalue you can use && to do that 10:29 < jonatack> jnewbery: that's the one! Ty 10:29 < jnewbery> there's a bit more about it here: https://stackoverflow.com/questions/3582001/advantages-of-using-forward/3582313#3582313 10:29 < jnewbery> and here: https://www.justsoftwaresolutions.co.uk/cplusplus/rvalue_references_and_perfect_forwarding.html 10:30 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 276 seconds] 10:30 < jnewbery> ok, I have another question that wasn't the notes. Can anyone explain what the ArgsManagerHelper is and why it exists? 10:30 < jnewbery> https://github.com/bitcoin/bitcoin/blob/8f14d2002b114195fccfe8479a70e323c5f3aa09/src/util/system.cpp#L165 10:33 < jnewbery> (you should all feel free to ask any questions at any point. Don't feel like you can't talk because I've asked a question) 10:34 < jnewbery> the ArgsManagerHelper was introduced in PR 11862. ajtowns explains why he added it here: https://github.com/bitcoin/bitcoin/pull/11862#discussion_r173870835 10:34 < emilengler> Got to go now, thank you already 10:34 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 10:35 < michaelfolkson> Sorry, it takes some time to go through the links posted :) 10:36 < jnewbery> I think that now ArgsManagerHelper has been reduced to just two functions, we should just get rid of it entirely and move those to be private functions of ArgsManager 10:36 < lightlike> jnewbery: it is for helper functions that need Access to ArgsManager's internal. But why it is not just part of ArgsManager. 10:37 < michaelfolkson> For security reasons? 10:37 < jnewbery> lightlike: I asked aj that question in the original PR. His response "These functions could just be private member functions of ArgsManager, but that would mean bumping util.h every time any of them need to be changed, which causes a lot of unnecessary recompilation." (https://github.com/bitcoin/bitcoin/pull/11862#discussion_r173870835) 10:37 < fjahr> AJ says to save compilation time, which I would have never thought of on my own 10:37 < jonatack> For friendly convenience 10:38 < jnewbery> fjahr: s/compilation time/recompilation time/ 10:38 < jonatack> perhaps an unneeded abstraction now 10:38 < jnewbery> next question: What is the univalue library, and how is it used in Bitcoin Core? How is it used in this PR? What are your thoughts about that? 10:39 < fjahr> I would say there is at least a comment missing if we have to look into old PR discussions to make sense of the existence of a class ;) 10:39 < jnewbery> (this _was_ in the notes, so you'll have had a bit more time to prepare for it) 10:39 < jnewbery> fjahr: that's a fair point 10:39 < jonatack> https://github.com/bitcoin-core/univalue 10:39 < ajonas> univalue lib is a universal type that encapsulates a JSON value. Used for communication with external utilities through the RPC interface (exclusively until #15935?) 10:40 < jnewbery> ajonas: exactly correct! 10:40 -!- nijynot [~nijynot@h-177-96.A785.priv.bahnhof.se] has quit [Quit: WeeChat 1.9.1] 10:40 < jonatack> A fork of the original for stability. 10:41 < jnewbery> I like the review comment here: https://github.com/bitcoin/bitcoin/pull/15934/commits/4a5e736dc4a22643b4f09181b3d7245727cee876#r337691812 where russ lists the methods expected in the interface 10:42 < jnewbery> (the code comment at https://github.com/bitcoin/bitcoin/pull/15934/commits/4a5e736dc4a22643b4f09181b3d7245727cee876 says that univalue could be replaced but doesn't give the interface requirements) 10:43 < michaelfolkson> Are there downsides to using the univalue library? 10:44 < jnewbery> michaelfolkson: not that I can think of 10:44 < jnewbery> the advantage is that it makes https://github.com/bitcoin/bitcoin/pull/15935 a lot easier 10:45 < jnewbery> on that point, let's go to the last question. 15935 adds a persistent read/write config file to the data directory. Have there been any other attempts to do this? Which do you prefer? 10:46 < jonatack> There was luke-jr's https://github.com/bitcoin/bitcoin/pull/11082 10:47 < jonatack> I haven't reviewed to have a preference yet. 10:48 < jnewbery> jonatack: yes, that's the only other one that I'm aware of 10:48 < jnewbery> people have been talking about writeable config for years though 10:49 < jonatack> One possible criticism of univalue ("more code") from luke-jr here: https://github.com/bitcoin/bitcoin/pull/15935#issuecomment-510023127 10:50 < jnewbery> what do other people think about that? 10:52 < fjahr> I did not have time to through either PRs but I feel people regularly stumble over how/where args are defined. So a single place makes sense to me. There was also this PR recently where the configs should be printed out in the logs. It shows that it's a pain for people. 10:52 < michaelfolkson> I don't like the idea of multiple of .conf files if I'm understood it correctly. As a user I just want to see the latest settings, I don't care the path those settings followed to the latest settings 10:53 < jonatack> Reasonable viewpoints on both sides AFAICT, these are typical legacy codebase and backward compat issues. 10:53 < jnewbery> Talkless: I see you're reviewing the PR right now (thanks!) Are you able to use github's 'review' feature rather than leave individual comments to spare people's notifications a bit? :) 10:53 < Talkless> jnewbery: I don't believe I am able to "actually" review, just passing by 10:53 < Talkless> oh, notifications.. haven't thought about that 10:54 < Talkless> sorry 10:54 < jonatack> Talkless: click on "Files changed" at the top and you should see a green "Review changes" button on the upper right. 10:54 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 10:55 < jnewbery> michaelfolkson: I think it's unavoidable that there should be a different files for read-only config and read-write config. I think ryanofsky's comment here is a good summary: https://github.com/bitcoin/bitcoin/pull/15935#issuecomment-515534538 10:55 < jnewbery> Talkless: no problem. Thanks for reviewing! 10:55 < michaelfolkson> Yeah I was thinking about that config in logs PR as well a lot during this. 10:55 < jnewbery> 5 minutes left. Any final questions? 10:56 < michaelfolkson> Why is it assumed I don't want to be listening node if I connect to specific peers? 10:56 < jnewbery> michaelfolkson: because if you specify `-connect=`, it's assumed that you _only_ want to connect to that peer 10:57 < jnewbery> you can connect to a specified peer and listen by also specifying `-listen=1` 10:57 < jonatack> ryanofsky: I agree with your last paragraph in https://github.com/bitcoin/bitcoin/pull/15935#issuecomment-515534538 on advanced users versus typical users. 10:57 < fjahr> How are chances we can remove these backward compatiblities? Has this been discussed? 10:57 < michaelfolkson> Ah ok. Personally I would want both but I'm sample size of 1 10:58 < ariard> I found the point made here interesting on how config files should be thought according to whom is going to use them https://github.com/bitcoin/bitcoin/pull/15935#issuecomment-515534538 10:58 < jnewbery> michaelfolkson: then specify `-connect= -listen` 10:58 < jonatack> ryanofsky: though I am unsure who typical users are and what are their capabilities. 10:58 < fjahr> How is the general mood towards a change that potentially breaks local node configs 10:58 < michaelfolkson> Yup got it ;) Just querying the default behavior 10:59 < jnewbery> fjahr: we try not to, but if it's a clear win then we might do it 10:59 < ryanofsky> fjahr, I think a lot of the strange behaviors can be probably be cleaned up. I think they just need to be considered individually 11:00 < jnewbery> DING! 11:00 < jnewbery> that's time 11:00 < jnewbery> thanks everyone :) 11:00 < sebastianvstaa> thanks 11:00 < fjahr> Thanks jnewbery! 11:00 < michaelfolkson> Thanks and everyone! 11:00 < jnewbery> any specific requests for next week? 11:01 < jonatack> Thanks jnewbery, ryanofsky, and everyone! 11:01 < lightlike> thanks! 11:01 < ryanofsky> i'd request #15931 wallet depth in chain pr (rereviewing that now) 11:01 < jnewbery> yes, thanks ryanofsky! 11:02 < jnewbery> ryanofsky: you missed it: https://bitcoincore.reviews/15931.html :) 11:02 < ryanofsky> wow, ok! 11:03 < ajonas> thanks jnewbery 11:03 < michaelfolkson> I would post the link for suggesting future PRs but I haven't got it to hand 11:04 < michaelfolkson> It is an issue on the GitHub repo 11:04 < michaelfolkson> https://github.com/bitcoin-core-review-club/bitcoin-core-review-club.github.io/issues/14 11:05 < michaelfolkson> has a few suggestions. I'll choose one of them 11:18 < jnewbery> log is up: https://bitcoincore.reviews/15934.html 11:19 < jonatack> thanks! 11:24 -!- sebastianvstaa [~sebastian@95.211.210.109] has quit [Quit: Leaving] 11:52 -!- mode/#bitcoin-core-pr-reviews [+o jnewbery] by ChanServ 12:00 -!- michaelfolkson [~textual@82-132-235-23.dab.02.net] has quit [Quit: Sleep mode] 12:03 < jonatack> One takeaway for me from today's meeting is to improve my understanding of C++ templates. 12:26 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:34 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack] 12:34 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews 12:35 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Client Quit] 12:35 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews 12:42 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds] 12:52 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 12:57 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 245 seconds] 12:59 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 13:09 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 245 seconds] 13:27 -!- ajonas [uid385278@gateway/web/irccloud.com/x-modritlassmlaytb] has quit [Quit: Connection closed for inactivity] 13:34 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 13:41 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds] 13:52 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 14:20 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 268 seconds] 14:20 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 14:45 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.4 - https://znc.in] 14:46 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 15:08 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 268 seconds] 15:24 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews 15:27 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has left #bitcoin-core-pr-reviews ["ERC (IRC client for Emacs 26.3)"] 15:45 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews 16:48 -!- lightlike [~lightlike@2001:16b8:5790:3e00:d138:55e0:afed:8cc1] has quit [Quit: Leaving] 17:34 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer] 17:36 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 268 seconds] 17:36 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 17:36 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has quit [Changing host] 17:36 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 17:49 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:c0cf:92fb:ed09:3579] has joined #bitcoin-core-pr-reviews 18:03 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:c0cf:92fb:ed09:3579] has quit [Quit: Sleep mode] 18:17 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in] 18:31 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.4 - https://znc.in] 18:34 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 19:06 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 19:35 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 19:40 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 19:40 -!- felixfoertsch [~felixfoer@92.117.37.70] has quit [Read error: Connection reset by peer] 19:41 -!- felixfoertsch [~felixfoer@i6DFA647E.versanet.de] has joined #bitcoin-core-pr-reviews 21:36 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 21:42 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] 23:32 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 240 seconds] 23:38 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 23:42 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]