--- Day changed Wed Oct 02 2019
01:16 < jonatack> Notes and questions for today's review club are up at https://bitcoin-core-review-club.github.io/16401.html
01:18 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
01:22 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]     
01:28 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 250 seconds]     
02:10 -!- jonatack [~jon@87-231-197-177.rev.numericable.fr] has joined #bitcoin-core-pr-reviews     
03:19 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
03:23 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]     
03:40 < jonatack> See also: BIP draft "Transaction Package Relay" https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
03:46 -!- jonatack [~jon@87-231-197-177.rev.numericable.fr] has quit [Ping timeout: 268 seconds]     
04:07 -!- awesome-doge [lplplpmatr@gateway/shell/matrix.org/x-itixbcprqkjavpyd] has quit [Remote host closed the connection]     
04:19 -!- awesome-doge [lplplpmatr@gateway/shell/matrix.org/x-xqvqtvpdlgckhobq] has joined #bitcoin-core-pr-reviews     
04:24 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews     
04:58 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 250 seconds]     
05:20 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
05:24 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
05:32 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews     
05:43 -!- lightlike [~lightlike@2001:16b8:57de:c200:1c3d:8693:ae7b:fc57] has joined #bitcoin-core-pr-reviews     
06:09 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
06:25 -!- Lauda [~quassel@unaffiliated/lauda] has left #bitcoin-core-pr-reviews ["https://quassel-irc.org - Chat comfortably. Anywhere."]     
06:25 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
06:30 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
07:51 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-pr-reviews     
08:01 -!- emilengler_ is now known as emilengler     
08:09 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]     
08:20 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]     
08:31 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
08:31 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
08:33 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews     
08:36 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 245 seconds]     
08:38 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]     
08:54 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:12 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
09:14 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
09:39 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews     
09:39 < sosthene> Hi, just so that I don't forget, make failed when I tried to build the PR, I compiled again the BerkelyDB and ran configure with the --disable-wallet flag and now it seems to compile
09:40 < sosthene> I still have the following warnings though
09:40 < sosthene> leveldb/util/logging.cc: In function ‘bool leveldb::ConsumeDecimalNumber(leveldb::Slice*, uint64_t*)’:
09:40 < sosthene> leveldb/util/logging.cc:58:40: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
09:40 < sosthene>            (v == kMaxUint64/10 && delta > kMaxUint64%10)) {
09:40 < sosthene>                                   ~~~~~~^~~~~~~~~~~~~~~
09:40 < sosthene> leveldb/port/port_posix.cc: In function ‘bool leveldb::port::HasAcceleratedCRC32C()’:
09:40 < sosthene> leveldb/port/port_posix.cc:60:15: warning: ‘ecx’ may be used uninitialized in this function [-Wmaybe-uninitialized]
09:40 < sosthene>    return (ecx & (1 << 20)) != 0;
09:40 < sosthene>           ~~~~~^~~~~~~~~~~~
09:42 < lightlike> hi sosthene, the leveldb warnings are usual. they are kind of annoying, I assume that they arent fixed because leveldb is third-party code that shouldn't be touched unless absolutely necessary.
09:46 < sosthene> ok thanks
09:46 < sosthene> to bad I didn't copy the other blocking error I had before that, it's to far in my terminal I can't scroll up to it now
09:46 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 245 seconds]     
09:46 < sosthene> anyway
09:47 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
09:51 < jonatack> We'll get started in about ten minutes.
09:55 < zenogais> Sounds good!
10:00 < jonatack> Hi all! Welcome to this week's episode of the Bitcoin Core PR Review club.
10:00 < jonatack> We usually start Bitcoin Core IRC meetings with a 'hi' so it's clear who's at keyboard. Feel free to say hi!
10:01 < jkczyz> hi     
10:01 < sosthene> hi     
10:01 < jonatack> This week, we're talking about PR #16401 "Package relay" by sdaftuar
10:01 < lightlike> hi     
10:01 < pinheadmz> hi     
10:02 < jonatack> which is part of his ongoing work to improve the privacy and resilience of Bitcoin's peer-to-peer network.
10:02 < fjahr> hi     
10:02 < jonatack> sdaftuar: (Would you like to say anything about this PR or the next steps? Feel free to jump in.)
10:02 < zenogais> hi     
10:02 -!- unstaffed-skylig [~unstaffed@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
10:03 < jonatack> As summarised by Dave Harding in Bitcoin Optech newsletter #65 at https://bitcoinops.org/en/newsletters/2019/09/25/
10:03 < jonatack> "Package relay could allow nodes to accept a transaction below the node’s minimum feerate if the transaction came bundled with a child transaction whose fee was high enough to pay the minimum feerate for both it and its parent.
10:03 < jonatack> If widely deployed, package relay would allow users who create transactions a
10:03 < jonatack> long time before broadcasting them (e.g. timelocked transactions or LN
10:03 < jonatack> commitment transactions) to safely pay the minimum possible fee.
10:03 < jonatack> When it came time to broadcast the transaction, they could use Child-Pays-For-Parent (CPFP) fee bumping to set an appropriate fee for the current network conditions."
10:04 < jonatack> A resource that I will add to the notes:
10:04 < jonatack> Suhas began a BIP draft entitled "Transaction Package Relay" here:
10:04 < jonatack> https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
10:04 < jonatack> Much to unpack this week.
10:04 < jonatack> A good strategy for situations like this is to break it down to smaller useful steps, while keeping the larger vision in mind.
10:05 < jonatack> Who reviewed the PR?
10:06 < pinheadmz> i did the best i could :-) mempool stuff is the most complicated!
10:06 < pinheadmz> but i read the bip as well and the test is very easy to follow
10:06 < kanzure> hi     
10:06 < zenogais> I did, it was definitely a more difficult one.
10:06 < fjahr> I did and I enjoyed it although I needed to through it multiple times
10:07 < sosthene> I didn't have much time today, I'm building it and hopefully will run the test before the end of session
10:08 < jonatack> TBH I spent the afternoon reviewing 16400 and 16401 and am not nearly done. There's a lot to look at and the ATMP refactoring in 16400 pretty much has to be reviewed before this PR.
10:08 < zenogais> The BIP draft here provides a lot of userful higher-level context on this PR.
10:09 < jonatack> Question: How to have your running bitcoind output the net logging?
10:09 < pinheadmz> -debug net
10:09 < jonatack> Hint: see bitcoin-cli help logging
10:10 < fjahr> A meta comment for newcomers: a pattern of commits in Bitcoin PRs that is very clear here and that I have seen several times now is: first lower level stuff, then higher level/usage of the lower level, then tests. This happens almost automatically when commits are well structured but each one should not have failing tests on it's own. As a results when you see this is makes sense to review the commits
10:10 < fjahr> backwards.
10:11 < fjahr> Anyone feel free to correct me if you disagree with this, may be just an anecdotal observation ;)
10:11 < pinheadmz> oh yeah i forgot theres a command to enable while already running: bitcoin-cli logging debug
10:11 < pinheadmz> sorry logging (["net"])
10:11 < jonatack> pinheadmz: yes, when bitcoind is already running
10:12 < jonatack> pinheadmz: right! bitcoin-cli logging '["net"]'
10:12 < jonatack> fjahr: Interesting thought!
10:14 < jonatack> Did anyone attempt to fix the test TODO?
10:14 < zenogais> Yes     
10:14 < zenogais> I also added another test around 3-tx packages: https://gist.github.com/etscrivner/19d5f942a973940aaaeb397bc5e0e0d9
10:14 < zenogais> fixed the TODO using assert_raises_rpc_error
10:15 < jonatack> zenogais: Nice! Can you share a gist?
10:15 < zenogais> Posted above I think?
10:16 < zenogais> https://gist.github.com/etscrivner/19d5f942a973940aaaeb397bc5e0e0d9
10:16 < jonatack> zenogais: thank you.
10:16 < pinheadmz> quick Q about the test framework: is there always a BaseNode? and then num_nodes adds two additional nodes?
10:17 -!- ajonas [uid385278@gateway/web/irccloud.com/x-dbhfjukdmcqrdksk] has joined #bitcoin-core-pr-reviews     
10:17 < jonatack> Proposing additional tests can be a good way to help a PR author.
10:17 < fjahr> I was not sure how much I should do with/comment on the tests since they were half-baked (still had comments from the example test) so stuck to the code. Also first time I have reviewed a draft PR tbh
10:17 < fjahr> jonatack: true
10:17 < jonatack> It's generally a well-appreciated contribution.
10:18 < jonatack> fjahr: Good point about the Draft status.
10:18 < jonatack> WIP and draft PRs are likely mainly looking for Concept and approach ACKs.
10:20 < jonatack> pinheadmz: In the test setup you can specify the number of nodes.
10:20 < lightlike> pinheadmz: not always: "BaseNode" is just a name; these derived classes are used when you need some extra functionality (such as extra logging etc.) beyond the basic P2PInterface class.
10:20 < jonatack> pinheadmz: Have a look at test/functional/example_test.py
10:20 < jonatack> pinheadmz: It's a functioning tutorial test
10:22 < pinheadmz> I sorta dont understand why we need one more add_p2p_connection on line 102 -- shoudlnt the connection already be established on line 67 ?
10:22 < jonatack> pinheadmz: lightlike: Yes. It depends on the includes at the top of the test fgile.
10:23 -!- baroobob [~jwbwater@208.77.22.116] has joined #bitcoin-core-pr-reviews     
10:23 < zenogais> The second add_p2p_connection is there for its return value.
10:23 < zenogais> Which is used to invoke send_and_ping
10:24 < pinheadmz> ok thats what i thought - it doesnt disconenect/ reconnect
10:24 < pinheadmz> so that p2p = could be up on line 67
10:24 < zenogais> I believe so, let me try it
10:24 < zenogais> yep, that works
10:25 < pinheadmz> confirmed as well
10:25 < pinheadmz> hey maybe ill comment!
10:26 < jonatack> Question: Who ought to be responsible for initiating package relay, the sender or the recipient?
10:26 < zenogais> I believe it's the sender, since they have to specify the package to relay.
10:26 < pinheadmz> the recipient first must signal they allow package messages
10:27 < pinheadmz> `sendpackages`
10:28 < pinheadmz> like how `sendheaders` is used to initialize headers-first sync from a peer
10:28 < jonatack> IIUC, it's a trade-off
10:28 < jonatack> The sender is well-positioned to know if package relay is needed
10:28 < jonatack> but a naive version could be bandwidth wasteful, and likely need p2p changes
10:29 < jonatack> The recipient can tell if a transaction's parents are missing
10:29 < jonatack> and request package relay from the sending peer
10:29 < jonatack> so package relay would only occur as needed
10:30 < jonatack> eg to/from low-memory-mempool nodes
10:30 < lightlike> in the current draft implementation, it seems that the recipient figures out when it can use package relay by themselves.
10:31 < jonatack> lightlike: Yes. I think recipient-initiated is the preferred approach.
10:32 < jonatack> Question: Should we update the p2p protocol to accommodate package relay, or rely on existing functionality?
10:32 < zenogais> Makes sense
10:32 < jonatack> (eg what are the trade-offs)
10:34 < jonatack> zenogais: IIUC, recipient-initiated adds the step of requesting the sender return the list, but saves the need for the sender to do broadcast it all the time
10:35 < pinheadmz> i thought it was interesting that the author added new p2p messages - at first i just expected it to be an expanded CPFP policy
10:36 < jonatack> On one hand, not updating the protocol means ease of upgrading the network.
10:37 < zenogais> Not chaning p2p also means decreased attack surface, especially since some of this verification logic is expensive.
10:37 < zenogais> jonatack: Yeah, I hadn't fully grasped these packages were being received, but reading through the BIP draft it makes more sense now.
10:38 < jonatack> zenogais: true. And more code and features can mean more attack surface.
10:38 < lightlike> there are no new p2p messages in the draft implementation though. What was changed there is only the behaviour if we receive a TX message with a too-low fee (searching for a fitting orphan and trying to build a 2-tx package)
10:38 < zenogais> ^ Yeah, which is why this looks sender initiated in the Draft PR
10:39 < jonatack> lightlike: Right. PR 16401 is proof of concept written before 16400 (ATMP refactoring) was merged.
10:39 < zenogais> One other trade-off here is that the functionality is a bit redundant with RBF
10:40 < fjahr> I think it is a worthwhile improvement without new messages but with new messages we get much higher efficiency
10:41 < jonatack> From what I've understood, the advantage of updating the p2p protocol would be potentially optimising network efficiency and computational complexity
10:41 < jonatack> fjahr: right
10:41 < zenogais> Yeah, otherwise I think there would be a lot more logic around detecting potential relay packages
10:41 < zenogais> With P2P message it's explicit
10:42 < jonatack> Yes. My money would be on updating. It's too tempting not to try :D
10:43 < zenogais> On the plus side, this also opens up some neat possibilities as pointed out in OpTech summary
10:44 < zenogais> Increases possibilities for reducing fee-rates
10:45 < jonatack> What about DoS vectors and the additional logic added with AcceptMultipleTransactions?
10:46 < zenogais> From the comment: "We will end up needing to recalculate setAncestors for each transaction prior to calling Finalize, but we should do the correct package-size calculations before we call ScriptChecks(), to avoid CPU-DoS."
10:46 < jonatack> Seems like more checks are involved. PreChecks maybe twice? etc.
10:46 < unstaffed-skylig> DoS was something I was trying see if it had been discussed on GH.  seems like resource exhaustion potential is much higher
10:47 < unstaffed-skylig> zenogais where is the comment "We will end up needing..."
10:48 < zenogais> DoS potential is a little worrying without there being some limit on package size.
10:48 < zenogais> src/validation.cpp Line 1107
10:48 < jonatack> Yes. For the complexity reason alone, upgrading/refactoring to simplify/make efficient looks necessary.
10:49 < jonatack> Also: 1) We would want the ability to perform policy checks on the whole package *before* signature validation to avoid CPU-exhaustion attacks
10:49 < jonatack> and (2) we need to be attentive of order-dependencies on mempool acceptance of (a) transaction relay and (b) transaction arrival to the node
10:50 < jonatack> Lots to do!
10:51 < zenogais> Yeah, would love to see the package policy validation in a single method so it could be tested against multiple types of packages. The logic here seems particularly tricky.
10:51 < jonatack> unstaffed-skylig: zenogais: yes
10:51 < jonatack> zenogais: I agree.
10:52 < jonatack> And yet we're talking about arguably the most critical sections of the codebase
10:54 < zenogais> Is there chain-split potential with this change as well?
10:54 < jonatack> Will need eyes and much more review... experienced reviewers. Why this club exists.
10:55 < jonatack> 5 minutes. Let's wrap up.
10:55 < unstaffed-skylig> zenogais: chain split beyond DoS'ing a mining node to take out effective hash power? That's the only scenario I can invision
10:55 < lightlike> i am not completely convinced yet if the use cases for package relay justify a non-minimal version of it with large and more complicated packages.
10:56 < jonatack> Any PR suggestions for next week?
10:56 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]     
10:57 < zenogais> Looking through PRs right now
10:57 < jonatack> lightlike: A systematic framework for simulating/testing p2p might be valuable for assessing this.
10:58 < lightlike> i think #16981 will be really interesting, but it's still WIP.
10:59 < jonatack> From what I understand, people like Giula Fanti, Suhas, and Gleb (among others would be interested in any contribution to such a framework.
11:00 < jonatack> Please add your PR suggestions and volunteer for hosting meetings on the club repository!
11:01 < zenogais> Will do, thanks jonatack
11:01 < jonatack> The link is: https://github.com/bitcoin-core-review-club/bitcoin-core-review-club.github.io/issues/14
11:01 < jonatack> Thanks, all!
11:01 < pinheadmz> thanks jonatack !
11:02 < fjahr> thanks jon!
11:02 < jonatack> Thanks to zenogais, fjahr, and pinheadmz for reviewing the PR!
11:02 < lightlike> thanks!
11:04 < jonatack> zenogais: thanks for adding tests!
11:05 < zenogais> Of course!
11:09 < jonatack> sosthene:, lightlike: about the build warnings, it's pretty hard to eliminate them for all platforms. From what I've seen, for example, there are many more warnings on some platforms than others.
11:09 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
11:10 -!- baroobob [~jwbwater@208.77.22.116] has left #bitcoin-core-pr-reviews ["WeeChat 2.4"]     
11:16 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]     
11:17 -!- unstaffed-skylig [~unstaffed@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews []     
11:17 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
11:50 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]     
11:56 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
12:07 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
12:10 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]     
13:03 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]     
13:06 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection]     
13:33 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
14:18 -!- lightlike [~lightlike@2001:16b8:57de:c200:1c3d:8693:ae7b:fc57] has quit [Remote host closed the connection]     
14:53 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 240 seconds]     
14:56 -!- jkczyz [~jkczyz@135.84.132.56] has joined #bitcoin-core-pr-reviews     
15:46 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has quit [Ping timeout: 276 seconds]     
15:47 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has joined #bitcoin-core-pr-reviews     
15:50 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has quit [Read error: Connection reset by peer]     
15:53 -!- seven_ [~seven@193.77.101.62] has joined #bitcoin-core-pr-reviews     
16:47 -!- seven_ [~seven@193.77.101.62] has quit [Read error: Connection reset by peer]     
16:52 < aj> seems like a productive review club this week!
16:53 < aj> fwiw, if you've got improvements to test cases etc, you can make "meta-PRs" -- ie, go to whoever created the PR's branch for the PR, then create a PR against *that*; they can then merge your patch via github if they like, which updates the original PR
16:55 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has joined #bitcoin-core-pr-reviews     
16:57 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has quit [Read error: Connection reset by peer]     
17:02 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has joined #bitcoin-core-pr-reviews     
18:25 -!- jkczyz [~jkczyz@135.84.132.56] has quit [Ping timeout: 245 seconds]     
19:09 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Ping timeout: 240 seconds]     
19:10 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
19:14 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
19:15 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
19:16 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews     
19:19 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]     
19:50 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
19:55 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
20:06 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has left #bitcoin-core-pr-reviews ["ERC (IRC client for Emacs 26.1)"]     
20:32 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
20:38 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds]     
22:33 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
22:38 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]     
22:53 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
23:11 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds]     
23:46 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
23:51 -!- jkczyz [~jkczyz@c-24-130-172-130.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds]