--- Log opened Wed Oct 06 00:00:28 2021 00:58 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection] 00:58 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #bitcoin-core-pr-reviews 02:04 -!- kexkey [~kexkey@static-198-54-132-92.cust.tzulo.com] has quit [Ping timeout: 252 seconds] 02:05 -!- kexkey [~kexkey@static-198-54-132-124.cust.tzulo.com] has joined #bitcoin-core-pr-reviews 03:05 -!- belcher_ is now known as belcher 07:31 -!- ziggie [uid521459@user/ziggie] has joined #bitcoin-core-pr-reviews 07:45 -!- kexkey [~kexkey@static-198-54-132-124.cust.tzulo.com] has quit [Ping timeout: 265 seconds] 07:46 -!- kexkey [~kexkey@modemcable241.140-175-137.mc.videotron.ca] has joined #bitcoin-core-pr-reviews 08:02 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 08:03 < KaizenKintsugi> hmm, is this different from free node? I couldn't connect on my irc client 08:16 < sipa> you seem to be connected fine, now 08:23 < KaizenKintsugi> Seems like, was hoping I could use my regular client. I'm a noob looking to learn how to contribute, I have time and some skill. 08:27 < ryanofsky> I haven't done a review club in a while, but I'd be interested in hosting a #22766 "Clarify and disable unused ArgsManager flags" review at some point if there is space, and it seems like a suitable PR 08:37 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 08:42 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 08:44 < sipa> KaizenKintsugi: it should work with a normal client 08:49 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 08:53 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 09:07 < KaizenKintsugi> Sipa: I will investigate 09:15 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 09:30 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 09:44 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 09:46 -!- gene [~gene@gateway/tor-sasl/gene] has joined #bitcoin-core-pr-reviews 09:48 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 09:49 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:56 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 10:00 -!- Azorcode [~Azorcode@201.211.37.206] has joined #bitcoin-core-pr-reviews 10:00 < jnewbery> #startmeeting 10:00 < jnewbery> Hi folks! Welcome to Bitcoin Core PR Review club! 10:00 < jnewbery> Feel free to say hi to let people know that you're here. 10:00 < raj> hi.. 10:00 < theStack> hi! 10:01 < svav> Hi 10:01 < KaizenKintsugi> hello! 10:01 < gene> hi 10:01 < KaizenKintsugi> This is my first time here so nice to meet everyone 10:01 < Azorcode> Hello Everyone 10:02 < jnewbery> KaizenKintsugi: Welcome! We love new review clubbers :) 10:02 < schmidty> hi 10:02 < jnewbery> anyone else here for the first time? 10:02 < KaizenKintsugi> jnewbery: ty 10:02 < jnewbery> (there are some tips here for first timers: https://bitcoincore.reviews/your-first-meeting) 10:02 < larryruane> hi! 10:02 < KaizenKintsugi> I have read 10:02 < jnewbery> Notes and questions for this week are here at https://bitcoincore.reviews/23157 10:03 < jnewbery> Who had a chance to read the notes / review the PR? (y/n) 10:03 < gene> y/y 10:03 < raj> y 10:03 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 10:03 < theStack> y/0.5y 10:04 < jnewbery> lots of 'y's. Great! 10:04 < jnewbery> ok, let's get into it. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? 10:04 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving] 10:04 < raj> Concept ACK. Yet to run the benches.. 10:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews 10:05 < raj> Also seems like a very clever approach to reduce computation load.. 10:06 < jnewbery> did anyone run the bench? 10:06 < gene> tested ACK 10:06 * gene ran bench 10:07 < larryruane> y 10:07 < jnewbery> gene: great. I see you posted your results to the PR as well. Thank you! 10:07 < jnewbery> larryruane: excellent. I see you also posted your results. 18x is a pretty good optimization. 10:07 < jnewbery> ok, next question. Is it important for these checks to be fast? Why/why not? 10:08 < gene> performance gains are definitely good 10:08 < raj> Because if the checks are fast enough, we can do it more often? Or maybe set a default interval for mainnet and not have it disable by default? 10:09 < jnewbery> gene: I agree that ceteris paribus, more performant is better 10:09 < schmidty> Encourages running the tests if they are faster :) 10:09 < jnewbery> schmidty: I agree. I think that's the most compelling justification 10:09 < jnewbery> Does anyone know when CTxMemPool::check() is run? 10:10 < larryruane> If this check is enabled via `-checkmempool`, does that mean the check code runs on each and every modification to the mempool? I would think that's too much for mainnet (even with these improvements) 10:10 < KaizenKintsugi> It looks like it is run on an interval? 10:11 < gene> by default turned off for all but regtest? 10:12 < jnewbery> larryruane: I agree that running on mainnet is probably not what we want to do. Even with the performance gains, I think it'd add too much load (and we maybe don't want to be adding asserts to nodes running mainnet) 10:12 < jnewbery> gene: right, only on by default for regtest 10:13 < jnewbery> KaizenKintsugi: not on an interval. Only after certain events 10:13 < KaizenKintsugi> ty 10:14 < raj> jnewbery, I can't seem to find the caller of CTxMemPool::check(), any pointer on that? 10:14 < jnewbery> It's actually only called in two places from net_processing, and once in validation. If you grep for ".check(" or ">check(" you'll find them 10:15 < theStack> one place seems to be the reception of a tx that was successfully accepted to the mempool 10:15 < jnewbery> theStack: correct. And the other one in net_processing is after processing an orphan transaction. The call from validation is at the end of ActivateBestChainStep() 10:16 < raj> jnewbery, Thanks.. 10:16 < jnewbery> but again, these only actually do anything if checks are enabled, which only defaults to on for regtest 10:17 < jnewbery> Did anyone try running the functional tests? I wonder if these changes make any difference to runtime (possibly not, since the mempools in the functional tests are mostly empty) 10:17 < jnewbery> ok, next question. What does the UpdateCoins() function do? What is it replaced with in this PR? 10:18 < raj> UpdateCoin marks the input of tx as spent, and update the coinsview with that transaction. 10:19 < raj> After this PR we just spend the coins from mempoolDuplicate directly. 10:19 < jnewbery> raj: exactly right 10:20 < jnewbery> UpdateCoin also populates a CTxUndo reference, which we don't need in the mempool check call 10:20 < jnewbery> next question. What was waitingOnDependants used for before this PR? Explain what this while loop was doing. Why can it now be removed? 10:21 < raj> waitingonDependant seems like just a list to store txs whose parent's haven't been validated yet. 10:21 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has joined #bitcoin-core-pr-reviews 10:22 < raj> The loop iterates over the waitline, check if the inputs are in mempoolDuplicate, if yes apply the tx, if not put it back into the list. 10:22 < jnewbery> raj: exactly right 10:22 < jnewbery> so what's the worst case here? 10:23 < raj> That none of the inputs are validated? and the tx has a long ancestry list? 10:25 < jnewbery> check() is iterating over the entries in mapTx, which may be in any order. Say my mempool contains 5 transactions A -> B -> C -> D -> E. What's the worst order they could be in? 10:25 < KaizenKintsugi> I will guess reverse? 10:25 < raj> E D C B A? 10:26 < gene> ^ 10:27 < jnewbery> right, so in the first iteration, we'll go through all the transactions and add (E,D,C,B) to the waitingOnDependants list, and then verify A 10:27 < larryruane> jnewbery: can you clarify the meaning of the arrows .. is A the parent of B? 10:27 < jnewbery> then in the while loop, we'll iterate over E,D,C and process B, then iterate over E,D and process C, and so on, then iterate over E and process D, and finally process E. 10:27 < KaizenKintsugi> larryruane: that is how I interpret it 10:28 < jnewbery> larryruane: apologies. B spends A's output (A is the parent of B) 10:28 < KaizenKintsugi> I assume we want to sort first, then process 10:28 < jnewbery> KaizenKintsugi: excellent idea! What do we sort by? 10:29 < raj> Number of ancestor, in ascending order. :) 10:29 < KaizenKintsugi> I will guess the amount of dependents, I read in the git comments that we want to sort by "topological order" but I dont know what that means 10:30 < larryruane> KaizenKintsugi: run `man tsort` 10:30 < KaizenKintsugi> I think it has something to do with a graph 10:30 < larryruane> (actually `info tsort` is better) 10:31 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 10:31 < jnewbery> raj: exactly right. What does CTxMemPoolEntry.nCountWithAncestors cache? 10:31 < KaizenKintsugi> larryruane: thanks 10:31 < raj> KaizenKintsugi, https://www.geeksforgeeks.org/topological-sorting/ 10:32 < theStack> larryruane: heh, nice. TIL a new unix command 10:32 < raj> jnewbery, assuming you are asking what it does, it simply stores the number of ancestor including the tx itself? 10:32 -!- BlockHead [~BlockHead@104-6-75-126.lightspeed.miamfl.sbcglobal.net] has joined #bitcoin-core-pr-reviews 10:33 < jnewbery> raj: correct 10:33 < jnewbery> and so if we sort by ascending ancestor count, then we guarantee that no child appears before its parent. Does that make sense to everyone? 10:34 < KaizenKintsugi> are the number of ancestors strictly in the mempool? or do these ancestors trace back to the coinbase? 10:34 < raj> parallel question, why is the ancestor count is termed as topology? Its just a linear graph right? 10:34 < jnewbery> KaizenKintsugi: an 'ancestor' here is an unconfirmed transaction that's in the mempool 10:34 < KaizenKintsugi> raj: I think it can branch 10:35 < KaizenKintsugi> jnewbery: ty 10:35 < gene> raj: you could also see the graph as a tree, with ancestors being parent nodes 10:35 < raj> But isn't a two transaction not suppose to have same parent? Thats a double spend.. 10:36 < jnewbery> raj: sorting by ascending ancestor count gives a partial ordering. The output of the topo sort is a total ordering that doesn't violate any of the partially ordered pairs 10:36 < jnewbery> raj: two transactions can have the same parent, if that parent created two transaction outputs 10:36 < gene> ^ 10:37 < raj> jnewbery, yes, but the inputs would be different (vout value). So that would still be considered as same parent? 10:37 < gene> but if you meant two parents, then yeah that would be double spend 10:37 < jnewbery> raj: yes, that's the same parent transaction 10:37 < raj> oh ok.. Thanks.. 10:38 < jnewbery> gene: no, a transaction can have inputs from multiple transactions. In that case, it has multiple parents 10:38 < gene> :) you're right 10:38 < KaizenKintsugi> ah yes, we can have transactions with N inputs and M outputs 10:38 < gene> so double spend == multiple parents with same UTXO input? 10:39 < jnewbery> a double spend is where two transactions are spending the same transaction output 10:39 < jnewbery> We've mostly done the next question, but perhaps someone could add some more detail. How does the GetSortedDepthAndScore() function work? Why does the returned vector not contain any descendants before their ancestors? 10:40 < raj> The sort works by, first sorting by ancestor count in ascending order, then by fee in descending order, then by hash value in descending order. 10:41 < raj> The last two parts are termed as "score", and the first part is termed as "depth". 10:41 < jnewbery> raj: right. We actually only care about the ancestor count for our purposes here 10:42 < jnewbery> but this SortedDepthAndScore() is also used elsewhere 10:42 < theStack> hope to not being to off-topic, but any specific reason why the hash value is included as third criteria for sorting? i can't think of a scenario where this really matters 10:42 < sipa> to make it unambiguous 10:42 < jnewbery> theStack: just as a tie-break I expect 10:43 < theStack> ok, makes sense 10:43 < raj> theStack, the sort will only take place when there's a tie in previous sort. 10:43 < larryruane> theStack: probably so the results are deterministic, may make testing easier (direct comparison of results to expected) 10:43 < raj> as far as I understand. 10:43 < sipa> what other tie breaker would you use? memory addresses? that might be a privacy leak even 10:43 < jnewbery> it's possible for depth and fee to be identical for two mempool transactions. txid breaks that tie 10:44 < jnewbery> ok, final question. GetSortedDepthAndScore() uses the CTxMemPoolEntry’s cached ancestor count to sort the transactions. What would happen if those cached values were incorrect? 10:45 < raj> jnewbery, the sort will not be correct, which will lead to trying validation of descendant before parent, and that will cause some error? 10:45 < gene> txs with chained inputs might fail 10:45 < raj> Also there is an sanity assertion check, that seems like it would fail. 10:45 < jnewbery> raj: yes, exactly right. https://github.com/bitcoin/bitcoin/blob/66d11b14357c474416181227e197406ca8fb5dee/src/txmempool.cpp#L750 10:46 < jnewbery> part of check() is checking that those cached values are correct. If any of those are wrong, then the mempool will be indexed incorrectly, which could lead to all kinds of problems 10:46 < jnewbery> ok, those were the only questions I'd prepared. Did anyone else have any other questions or comments? 10:47 < raj> as we are not doing the check() by default, so in regular cases we are just hoping that these kind of bad stuffs of mempool inconsistency doesn't happen? 10:47 < raj> What does the node do when it does happen? will i see a crash? 10:48 < jnewbery> we run check() by default in the functional tests. It's pretty usual to have these kinds of sanity checks enabled in test and disabled in production 10:48 < gene> how many fuzzers target the mempool code? 10:48 < jnewbery> gene: good question! The code is in src/test/fuzz/tx_pool.cpp 10:49 < gene> jnewbery: thanks! 10:49 < raj> jnewbery, ya makes sense. so its more like consistency for the protocol, not a running node. would that be a correct way to put it? 10:49 < raj> *consistency check 10:50 < jnewbery> I wouldn't use the word protocol there, since the mempool is an internal implementation detail. 10:50 < jnewbery> it's a consistency check that we run in our tests, but not (by default) in production 10:50 < raj> understood.. thanks.. 10:51 < gene> jnewbery: so if another node impl has different mempool code, would that cause any net/consensus issues? 10:51 < larryruane> so this PR modifies checking code ... that could possibly break it ... Anyone have ideas on how to check the checking code? 10:51 < raj> just curious, in case of some other impls (say btcd) would the consistency check logic look same? Or thats dependent on mempool implementation? 10:51 < jnewbery> gene: no! That's basically what I mean by implementation detail 10:52 < jnewbery> nodes are free to implement whatever mempool they want, and whatever policy rules for accepting transactions into their mempool that they want. 10:52 < gene> awesome, that is counterintuitive. good to know 10:52 < jnewbery> I expect at some point pretty soon, we'll have a -nomempool option that disables the mempool entirely 10:52 < KaizenKintsugi> yea this is a surprise to me too 10:53 < larryruane> jnewbery: yes, I thought I'd heard that miners likely have made proprietary changes to the mempool code (even if running core), but we don't know for sure 10:53 < jnewbery> larryruane: very good question! Anyone have any suggestions on how to check the checking code? 10:53 < gene> run against test vectors from other impls 10:54 < jnewbery> gene: other impls won't have the same mempool code 10:54 < jnewbery> the mempool is an implementation detail 10:54 * gene facepalms 10:55 < raj> ya this was the biggest surprise to me too. Took some time to absorb.. :D 10:55 < larryruane> if i may offer an answer ... you must break the code and verify that the checking code catches it 10:55 < jnewbery> larryruane: one way might be to introduce changes to the mempool code itself, and then see if both the new check and old check assert 10:55 < jnewbery> snap! 10:55 < larryruane> (obviously this is manual testing, no need to automate this!) 10:56 < gene> automated mutations could be intereting test code 10:56 < jnewbery> yes, this is called mutation testing: https://en.wikipedia.org/wiki/Mutation_testing 10:57 < sipa> mutation testing led to the discovery of a 20% faster variant of the safegcd modular inverse algorithm ;) 10:57 < jnewbery> sipa: fun fact! 10:57 < larryruane> oh so you _can_ automate this type of testing! 10:57 < sipa> jnewbery: very fun 10:57 < raj> Whats the difference between mutation and fuzzing? 10:58 < BlockHead> I'm assuming mutation tests are a type of fuzzy test? 10:58 < jnewbery> raj: mutation is mutating the source code. Fuzzing is providing random inputs to the code 10:58 < jnewbery> ~random 10:58 < sipa> (or better than random) 10:58 < gene> fuzzing dictionaries are nice! 10:58 < jnewbery> right, not at all random in fact :) 10:58 < raj> oh.. so its like the code text itself is being changed? 10:59 < sipa> and mutation testing is a way of testing *the tests* 10:59 < sipa> fuzz testing is testing the code 10:59 < sipa> (at least the forms i'] familiar with) 10:59 < jnewbery> raj: exactly. Break the code in lots of different ways and test that the tests catch them 11:00 < raj> Got it.. thanks.. 11:00 < jnewbery> This was a fun tangent. Thanks larryruane! 11:00 < jnewbery> ok, that's time 11:00 < jnewbery> #endmeeting 11:00 < larryruane> our fuzz tests tend to focus on one small subsystem at a time ... any thought been given to fuzz testing at the functional test level? start up a bunch of nodes and throw semi-random stuff at it? 11:00 < larryruane> thanks jnewbery this was great 11:00 < KaizenKintsugi> Damn, I learned so much, this is so awesome 11:00 < theStack> thanks for hosting jnewbery! 11:00 < jnewbery> thanks everyone for participating. Hope you all enjoyed! 11:00 < raj> thanks jnewbery this was a great one.. 11:00 < gene> thanks jnewbery 11:00 < KaizenKintsugi> Thanks! yea this is super humbling. 11:01 < KaizenKintsugi> see you all next week! 11:01 < gene> ./ 11:02 < gene> are there any mutation tests in bitcoin-core? (if not I'm interested now) 11:02 < jnewbery> larryruane: I'm not sure if anyone's tried it. I expect it might be difficult since the p2p interface requires very specific input (eg each message contains a checksum, a block message must contain valid pow, etc), that it'd be difficult to have a fuzzer be able to penetrate into deep code paths I expect. 11:03 < jnewbery> but I'm certainly not an expert on fuzzing 11:03 < sipa> gene: mutation testing isn't something that "there is", it is something *you do* 11:03 < sipa> larryruane: there are fuzz tests that feed fuzz input as p2p messages 11:03 < BlockHead> oh so its just a refactor till a breaks type of situation? 11:03 < gene> sipa: not sure I understand. do you mean it's like continual fuzzing? 11:04 < sipa> gene: no, it's not something automated 11:04 < KaizenKintsugi> Any suggestions of where I should start learning the code base? 11:04 < larryruane> jnewbery: I was thinking more of submitting semi-random RPCs to the various nodes (not having the python code send P2P messages directly, if that's what you were suggesting) 11:04 < sipa> gene: like, you, today, could go in the code, start introducing bugs, recompile, and see if the tests fail 11:04 < gene> right, so is continuous fuzzing like OSSFUZZ 11:04 < sipa> gene: fuzzing is completely different 11:04 < larryruane> sipa: just don't let it get merged :) 11:05 < sipa> gene: if you can introduce a bug in the code which the tests don't catch, you've succesfully found an inadequacy in the tests, through mutation testing 11:05 < gene> lol, I understand how to do mutation testing manually, but I found some C++ frameworks to do it automatically: https://github.com/mull-project/mull 11:05 < raj> KaizenKintsugi, I would suggest reviewing PRs is the best place to start. Because if you try to read the codebase from anywhere, you would get lost very soon. 11:06 < sipa> gene: ah, sure, we have no such automated infrastructure 11:06 < KaizenKintsugi> raj: thanks, ill start there this is def overwhelming 11:06 < gene> I could play around with the framework a bit, see if if finds anything interesting 11:07 < larryruane> KaizenKintsugi: I also recommend Jimmy Song's book Programming Bitcoin, it's excellent 11:07 < KaizenKintsugi> yea I took his workshop a couple years ago 11:08 < KaizenKintsugi> I have a solid high-level overview 11:08 < raj> if you wanna read something serially then the best place to do that would be the functional tests. 11:08 -!- Azorcode [~Azorcode@201.211.37.206] has quit [Quit: Connection closed] 11:08 < sipa> gene: for anything but a tiny isolated piece of code i suspect it's practically useless 11:09 -!- BlockHead [~BlockHead@104-6-75-126.lightspeed.miamfl.sbcglobal.net] has quit [Quit: Connection closed] 11:10 < gene> sipa: yeah, but you've piqued my interest. my curiosity must be satiated 11:10 < gene> s/pique/picque 11:10 < sipa> :) 11:11 < sipa> larryruane: i don't think there are fuzz tests that go through RPC; fuzzing at such high level may be vefy slow 11:13 -!- kexkey [~kexkey@modemcable241.140-175-137.mc.videotron.ca] has quit [Ping timeout: 245 seconds] 11:15 -!- kexkey [~kexkey@static-198-54-132-156.cust.tzulo.com] has joined #bitcoin-core-pr-reviews 11:17 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 11:27 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 11:39 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 11:39 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 11:49 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 11:49 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 11:55 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 11:56 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 12:00 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Client Quit] 12:00 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 12:07 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Ping timeout: 265 seconds] 12:22 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:31 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has quit [Remote host closed the connection] 12:31 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews 12:42 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 12:47 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Ping timeout: 265 seconds] 12:59 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 13:03 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Ping timeout: 245 seconds] 13:17 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 13:44 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 13:45 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 13:53 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 13:53 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 13:59 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 13:59 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:05 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:06 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:12 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:12 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:21 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:21 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:26 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:26 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:27 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has quit [Remote host closed the connection] 14:27 -!- yonson [~yonson@2600:8801:d900:7bb:1e69:7aff:fea2:4e85] has joined #bitcoin-core-pr-reviews 14:32 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:33 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:39 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:39 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:40 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 265 seconds] 14:44 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Client Quit] 14:44 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:51 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:51 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 14:57 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 14:57 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:05 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 15:05 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:10 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Client Quit] 15:10 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:15 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Client Quit] 15:15 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:20 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 15:20 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:25 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Client Quit] 15:25 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:33 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 15:33 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:34 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Ping timeout: 276 seconds] 15:37 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Client Quit] 15:37 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:44 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Ping timeout (120 seconds)] 15:44 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has joined #bitcoin-core-pr-reviews 15:49 -!- KaizenKintsugi [~KaizenKin@d137-186-173-66.abhsia.telus.net] has quit [Quit: Connection closed] 16:21 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 264 seconds] 16:34 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews 17:35 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has quit [Remote host closed the connection] 17:35 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews 19:43 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has quit [Quit: Connection closed] --- Log closed Thu Oct 07 00:00:29 2021