--- Log opened Wed Nov 10 00:00:28 2021 00:41 < jnewbery> Kaizen_Kintsugi: yeah, it's a challenging one! 00:41 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #bitcoin-core-pr-reviews 02:03 -!- kexkey [~kexkey@static-198-54-132-165.cust.tzulo.com] has quit [Ping timeout: 264 seconds] 02:04 -!- kexkey [~kexkey@static-198-54-132-165.cust.tzulo.com] has joined #bitcoin-core-pr-reviews 03:44 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 03:45 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 264 seconds] 03:46 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 276 seconds] 04:25 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews 04:32 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 04:32 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 05:10 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 05:10 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 05:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 05:55 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 06:12 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 06:12 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 06:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 06:56 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 07:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 07:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 07:15 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 07:49 -!- seaona [~seaona@102.red-83-50-251.dynamicip.rima-tde.net] has joined #bitcoin-core-pr-reviews 07:53 -!- common [~common@096-033-221-075.res.spectrum.com] has quit [Remote host closed the connection] 07:54 -!- common [~common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews 07:54 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 08:05 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 08:06 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 08:11 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 08:18 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 08:37 -!- sm0l [~sm0l@2a01:799:5f:ec00:670c:fbd9:1c27:c55e] has joined #bitcoin-core-pr-reviews 08:41 < jnewbery> Hi folks. We'll get started in 20 minutes. If your clocks went back last weekend that may be a bit earlier than you were expecting! 08:46 -!- MaxDoronin [~MaxDoroni@host81-146-62-223.range81-146.btcentralplus.com] has joined #bitcoin-core-pr-reviews 08:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 08:55 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 08:57 < dongcarl> My thanks to all those who worked their way through the commits :-) 08:58 -!- common [~common@096-033-221-075.res.spectrum.com] has quit [Remote host closed the connection] 08:59 -!- common [~common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews 08:59 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has joined #bitcoin-core-pr-reviews 09:00 < jnewbery> #startmeeting 09:00 < glozow> hi 09:00 < michaelfolkson> hi 09:00 < glozow> #initmeeting 09:00 < jnewbery> hi folks. Welcome to Bitcoin Core PR Review Club! Feel free to say hi to let everyone know you're here 09:00 < sm0l> hi 09:00 < jnewbery> glozow: hoho 09:00 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has joined #bitcoin-core-pr-reviews 09:01 < dongcarl> hi 09:01 < lightlike> hi 09:01 < stickies-v> hi everyone! 09:01 < seaona> hi! 09:01 < jnewbery> Anyone here for the first time? 09:01 < jnewbery> dongcarl: thanks for joining us! 09:01 < michaelfolkson> config option: enable glozow jokes 09:01 < dongcarl> Wouldn't miss it! 09:02 < jnewbery> Notes and questions are in the normal place: https://bitcoincore.reviews/23280 09:02 < jnewbery> Who had a chance to read the notes & questions / review the PR this week? (y/n) 09:02 < MaxDoronin> I'm new here, jnewbery 09:03 < michaelfolkson> 0.5y 09:03 < lightlike> y 09:03 < sm0l> 1/2 y, read throught the code and tried to answer the questions 09:03 < sm0l> through* 09:03 < seaona> 0.5y 09:03 < jnewbery> MaxDoronin: welcome! We love new participants. Feel free to ask questions at any time 09:04 < stickies-v> 0.5y 09:04 < jnewbery> Any concept/approach ACKs or NACKs? What do you all think of the PR from a high level? 09:05 < stickies-v> Concept ACK - carve outs like LoadChainstateSequence make the code so much easier to understand and test 09:06 < sm0l> Concept ACK from me, seems like a good idea to clean up this code to pave the way for better testing and future maintaining 09:06 < michaelfolkson> Certainly can't think of any reason to NACK it 09:06 < lightlike> concept ACK, also makes a lot of sense to me to reuse init code in the unit test setup 09:07 < jnewbery> stickies-v: I agree. AppInitMain() is a beast, so pulling out logical units of the code seem like an improvement, especially if it means improving the test quality. 09:07 < jnewbery> ok, let's get into the code. This PR distinguishes between “soft failures” and “hard failures” when loading the chainstate. What is the difference between those two? 09:07 -!- matt50 [~matt@97-122-190-135.hlrn.qwest.net] has joined #bitcoin-core-pr-reviews 09:08 < michaelfolkson> Whether a failure can be recovered from with a reindex 09:09 < glozow> copy-paste: 09:09 < glozow> Soft failure - a failure that might be recovered from with a reindex 09:09 < glozow> Hard failure - a failure that definitively cannot be recovered from with a reindex 09:09 < sm0l> A soft failure is a failure we might be able to recover from while a hard failure is a failure we definitely cannot recover from 09:09 < michaelfolkson> And a failure being a corrupted datadir? 09:09 < michaelfolkson> Or data missing... 09:10 < jnewbery> michaelfolkson glozow: right, a failure is 'soft' if we can recover from it with a reindex 09:10 < jnewbery> what do we mean by reindex? 09:10 < stickies-v> I think to add, from my understanding the diff between soft/hard used to be a boolean true/false response, whereas nowadays this difference is not as binary anymore since we return a ChainstateLoadingError? 09:10 < michaelfolkson> Or an already locked datadir would be a failure to I think 09:11 < michaelfolkson> *too 09:11 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:11 < dongcarl> stickies-v: It actually used to be that a hard failure used to return from AppInitMain altogether 09:11 < jnewbery> stickies-v: this PR introduces the terminology of hard/soft failure (in the commit messages) 09:12 < dongcarl> whereas a soft failure would break (basically a goto) and proceed to some failure handling logic 09:12 < lightlike> the distinction is a bit unclear though imo. "ERROR_BLOCK_FROM_FUTURE" is treated as a soft failure, but won't be healed by reindexing, instead of fixing your time 09:13 < michaelfolkson> A reindexing of the blockchain. So we are talking using block data we already have available to us to create a UTXO set....? I'm not actually sure 09:13 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 276 seconds] 09:14 < jnewbery> lightlike: good point. Perhaps a better definition is that if it's a hard failure then we can never rebuild our chain state with the data in our datadir. If it's a soft failure, we may be able to recover with the data in our datadir. Is that more accurate? 09:15 < lightlike> jnewbery: yes, that makes sense to understand it that way 09:16 < jnewbery> reindex will rebuild both the chain state (UTXO set) and block index from the blk files on disk 09:16 < dongcarl> lightlike: Ah, I think that case is why I added the "might" in my message... 09:16 < jnewbery> can anyone give an example of a hard failure? 09:16 < Kaizen_Kintsugi> hi shit i'm late 09:16 < seaona> error bad genesis block ? 09:17 < michaelfolkson> Corrupted datadir? 09:17 < jnewbery> seanoa: bingo! 09:18 < jnewbery> That's kind of a pathological failure case where somehow the datadir has been mixed up with the datadir from a testnet node or something. 09:18 < jnewbery> I think that's the only hard failure. We should be able to recover from everything else 09:18 -!- Azorcode [~Azorcode@190.74.245.156] has joined #bitcoin-core-pr-reviews 09:19 < jnewbery> seaona: oops sorry mistyped your name 09:19 < jnewbery> next question: The first commit (init: Extract chainstate loading sequence) touches a large number of lines and extracts logic from AppInitMain() into a dedicated LoadChainstateSequence() function. How did you satisfy yourself that this commit didn’t introduce any behaviour changes? 09:20 < seaona> I was thinking all these were hard failures: 09:20 < seaona> ERROR_LOADING_BLOCK_DB 09:20 < seaona> ERROR_BAD_GENESIS_BLOCK 09:20 < seaona> ERROR_PRUNED_NEEDS_REINDEX 09:20 < seaona> ERROR_LOAD_GENESIS_BLOCK_FAILED 09:20 < seaona> np =D 09:21 < Kaizen_Kintsugi> jnewbery: would this be solved by passed tests 09:22 < Kaizen_Kintsugi> in testing setup 09:22 < lightlike> using the git flags mentioned in the commit message helps 09:22 < Kaizen_Kintsugi> load chain state sequence is called 09:23 < Kaizen_Kintsugi> *LoadChainstateSequence 09:23 < michaelfolkson> Looking over the code or playing with James' new functional test, there are no unit tests 09:23 < jnewbery> seaona: take a look at the first commit (init: Extract chainstate loading sequence), and the commit log (Currently, LoadChainstateSequence returns a bool which: - if false - Definitely a "Hard failure"). There's only one place in the function that returns false, and it's the "If the loaded chain has a wrong genesis, bail out immediately" part 09:23 < jnewbery> Kaizen_Kintsugi: alas, this area of the code is not well covered by unit tests 09:23 < Kaizen_Kintsugi> ah 09:24 < jnewbery> lightlike: I agree. `--color-moved=dimmed_zebra --color-moved-ws=allow-indentation-change` are very helpful flags for reviewing these mostly move-only commits. Kudos to dongcarl for including that review tip in the commit log. 09:25 < Kaizen_Kintsugi> git flags? 09:25 < seaona> jnewberry: thank you! 09:25 < dongcarl> 😊 09:26 < jnewbery> I'd say that in the absence of test coverage, we need to be extra careful in our code review. Here, the commit is moving code into a separate function. We can satisfy ourselves that it's basically move only by using that `git diff` command, and the arguments are almost all (mutable) references, so there shouldn't be any difference between changing those variables inside the function from 09:27 < jnewbery> the way it was done before. 09:27 < lightlike> Kaizen_Kintsugi: you do "git diff --color-moved=dimmed_zebra --color-moved-ws=allow-indentation-change" and everything that is just moved is marked in gray, so you see the differences more easily. 09:27 < jnewbery> was this pure move-only or were there any differences before and after the move? 09:28 < Kaizen_Kintsugi> thx lightlike 09:28 < Kaizen_Kintsugi> jnewbery function inputs changed i think 09:28 < Kaizen_Kintsugi> ass things decoupled 09:28 < Kaizen_Kintsugi> *as 09:29 -!- gene [~gene@gateway/tor-sasl/gene] has joined #bitcoin-core-pr-reviews 09:29 < jnewbery> I'm specifically talking about this commit: https://github.com/bitcoin-core-review-club/bitcoin/commit/f24e12f039edec70dfe30885b7a6082ccd3cf8e8 09:29 < stickies-v> lightlike Kaizen_Kintsugi you can also use a slightly shorter command with git show: "git show --color-moved=dimmed_zebra --color-moved-ws=allow-indentation-change" 09:30 < jnewbery> try it right now if you want 09:30 < jnewbery> git diff f24e12f039edec70dfe30885b7a6082ccd3cf8e8~ f24e12f039edec70dfe30885b7a6082ccd3cf8e8 --color-moved=dimmed_zebra --color-moved-ws=allow-indentation-change 09:30 < Kaizen_Kintsugi> the do while was removed, which confused me why that it was there in the first place 09:30 < jnewbery> Kaizen_Kintsugi: no, the do-while loop is still there after this commit 09:31 < jnewbery> it's important to review the PR commit-by-commit to be able to see what's changing 09:31 < Kaizen_Kintsugi> derp 09:31 < jnewbery> anyone see any non-move changes in that commit? 09:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 09:32 < jnewbery> how about this: 09:32 < jnewbery> - chainstate->CoinsErrorCatcher().AddReadErrCallback([]() { 09:32 < lightlike> there is a small diff in the first one, the line "chainstate->CoinsErrorCatcher().AddReadErrCallback([&]() {" gets an additional "&" 09:32 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews 09:32 < jnewbery> + chainstate->CoinsErrorCatcher().AddReadErrCallback([&]() { 09:32 < jnewbery> lightlike: excellent observation! 09:33 < jnewbery> if you're reviewing refactors, you need to be on the lookout for even tiny changes like that if you want to satisfy yourself that there aren't behaviour changes 09:33 < jnewbery> So what does that extra & do? 09:34 < glozow> capture local vars by reference 09:35 < glozow> s/local/used 09:36 < jnewbery> glozow: very nice! Yes, this is the captures for the lambda function. Previously it wasn't capturing anything, and now it's capturing local variables by reference 09:36 < jnewbery> why is that change required here? 09:36 < Kaizen_Kintsugi> needs fReindexChainState and fLoaded? 09:37 < Kaizen_Kintsugi> and the chainstate i guess 09:37 < pg156> jnewbery: "be on the lookout for even tiny changes" means looking at and reasoning about the code side by side? anything else? (as you also said "this area of the code is not well covered by unit tests") 09:38 < jnewbery> Kaizen_Kintsugi: that's not it. Let's have a look at what's happening inside that lambda 09:38 < jnewbery> { 09:38 < jnewbery> uiInterface.ThreadSafeMessageBox( 09:38 < jnewbery> _("Error reading from database, shutting down."), 09:38 < jnewbery> "", CClientUIInterface::MSG_ERROR); 09:38 < jnewbery> } 09:38 < jnewbery> which variable needed to be captured? 09:38 < glozow> mm easy to check, just need to remove the `&` and see what the compiler says 09:39 < Kaizen_Kintsugi> the CClientUIInterface? 09:39 < Kaizen_Kintsugi> uiInterface sry 09:39 < Kaizen_Kintsugi> which we want to decouple 09:39 < jnewbery> pg156: yes, use a diff tool to see the differences in the code and figure out what each of those differences imply 09:40 < jnewbery> Kaizen_Kintsugi: yes, it's uiInterface! So why didn't we need to capture it before, and we do need to capture it inside the new function? 09:41 < jnewbery> hint: https://github.com/bitcoin/bitcoin/pull/23280#discussion_r743923908 09:42 < Kaizen_Kintsugi> is it that we are replacing the string errors with these enum values like ChainstateLoadingError::ERROR_LOADING_BLOCK_DB 09:42 < lightlike> because it wasn't local in the context of init.cpp but global, but is local after the move? 09:42 < dongcarl> lightlike: bingo! 09:42 < jnewbery> lightlike: sir, you dropped this 👑 09:43 < dongcarl> 😆 09:43 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 09:43 < Kaizen_Kintsugi> cool 09:43 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:43 < lightlike> is there a good way to check where the global var is defined? git grep is problematic 09:44 < lightlike> too many lines 09:44 < jnewbery> yes, these things called uiInterface are actually different things! In the code before the commit, uiInterface is a global variable. After the commit, uiInterface is a local variable in the new LoadChainstateSequence() function 09:44 < dongcarl> lightlike: I use SourceTrail but there are other tools for this too 09:45 < jnewbery> ligthlike: here you go: https://github.com/bitcoin/bitcoin/blob/38b2a0a3f933fef167274851acaad0fd9104302a/src/node/ui_interface.cpp#L12 09:45 < jnewbery> I use exuberant ctags. Works most of the time, but didn't actually work here 09:46 < jnewbery> I just happen to know that uiInterface is declared in ui_interface.cpp 09:46 < dongcarl> The two vars do refer to the exact same thing though. I kept it named the same so that git’s move detection algorithm is happy. 09:47 < michaelfolkson> https://www.sourcetrail.com/blog/discontinue_sourcetrail/ :( 09:47 < jnewbery> right, so this function has a local variable called uiInterface, which is a reference to the global variable uiInterface. Having multiple variables named the same way is called "shadowing" and it's what Cory is talking about here: https://github.com/bitcoin/bitcoin/pull/23280#discussion_r743923908. 09:48 < jnewbery> It's maybe not such a big deal because this is only an intermediate commit and it gets cleaned up later 09:48 < jnewbery> but it is slightly confusing, as Cory points out 09:49 < Kaizen_Kintsugi> shit, I see it now 09:49 < dongcarl> True, perhaps I should add to the commit message 09:50 < jnewbery> an alternative approach would be to have a commit before this one that creates a reference to uiInterface in AppInitMain() called ui_interface or whatever, and uses that in the code that's about to be moved, then moves it with that name 09:50 < jnewbery> the first commit would have to update the lambda capture to capture that local reference 09:50 < jnewbery> but the second commit would then be a pure move of the code 09:51 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 09:51 < dongcarl> ah, good point! 09:51 < jnewbery> it's a bit circuitous, but it's maybe less mental strain for reviewers 09:51 < jnewbery> we have 9 minutes left. Let's get on to the next question 09:51 < jnewbery> Commit init/chainstate: Decouple from stringy errors changes the return type of LoadChainstateSequence() from a boolean to an (optional) enum. How did you satisfy yourself that the commit didn’t introduce any behaviour changes? 09:52 < pg156> The commit log addresses the question. I haven't completed this. But as a reviewer, I feel I need to enumerate all possible outcomes where `LoadChainstateSequence` is called, to compare before and after. 09:52 -!- RandyMcMillan [~RandyMcMi@47.205.7.87] has joined #bitcoin-core-pr-reviews 09:52 < dongcarl> Yeah this is probably the second trickiest commit in this PR, after the RPCNotify one 09:53 < dongcarl> Happy to improve the commit message if anything was confusing to folks 09:53 < jnewbery> pg156: indeed, you need to carefully look at all of the places where we exit due to an error, and verify that we're doing the same thing before and after 09:53 < dongcarl> Also, it might be easier to review after I implement https://github.com/bitcoin/bitcoin/pull/23280#discussion_r743703915 09:54 -!- _aj_ [aj@user/aj/x-5857768] has quit [Ping timeout: 264 seconds] 09:55 < lightlike> actually an InitError seemed to have gotten lost in that commit, but there was already a review comment on that (as for everything else I noticed during review) 09:55 -!- _aj_ [aj@cerulean.erisian.com.au] has joined #bitcoin-core-pr-reviews 09:55 -!- _aj_ [aj@cerulean.erisian.com.au] has quit [Changing host] 09:55 -!- _aj_ [aj@user/aj/x-5857768] has joined #bitcoin-core-pr-reviews 09:55 < jnewbery> I think the key observation is that the break statements become return statements that return error codes, and then the caller handles those error codes 09:55 < dongcarl> Yup, totally my b 😬 09:55 < Kaizen_Kintsugi> oh cool that commit message explains that do/while(false) loop 09:56 < Kaizen_Kintsugi> You don't need it anymore when returning a chainstateloading error 09:57 < dongcarl> Right! Previously, the do/while(false) + break combination was basically used to emulate goto's 09:57 < jnewbery> Kaizen_Kintsugi: exactly! The do-while is just there so it's possible to break out of that block of code. It's a very ugly way of replicating what can be done with a function and return statements 09:57 < jnewbery> dongcarl: right, or goto 09:57 < jnewbery> functions are much nicer :) 09:57 < dongcarl> hear hear! 09:58 < jnewbery> ok, maybe time for one very quick question to end 09:58 < jnewbery> In the same commit, why are the failed_chainstate_init and failed_verification local variables removed? What were they used for previously? Why are they no longer required? 09:58 < lightlike> i looked the pattern up on someone on stackoverflow called it "an idiotically disguised goto" 😉 09:58 < pg156> - They were used previously to break out of the chainstate activation do-while loop to return true (more specifically indicating a soft failure, as it is neither "Success" nor "Shutdown requested"). 09:58 < pg156> - They are no longer needed and therefore are removed, because 09:58 < pg156> - before the change: the effect of calling `LoadChainstateSequence` is captured by the function return value together with mutable function parameters (e.g. `fLoaded`, `strLoadError`). E.g. when db fails to upgrade, `failed_chainstate_init` is necessary to break out of the do-while loop, and set return value to true outside the loop. 09:58 < pg156> - after the change, e.g. when db fails to upgrade, the function can directly return an error status value `ERROR_CHAINSTATE_UPGRADE_FAILED` capturing the effect. 09:59 -!- danp [~danp@c-24-22-73-109.hsd1.or.comcast.net] has joined #bitcoin-core-pr-reviews 10:00 < Kaizen_Kintsugi> we now return before those local variables 10:00 < jnewbery> pg156: yes, I think that's exactly it 10:00 < jnewbery> now that we're returning an error code to indicate failure, we can do it directly at the point of the failure 10:00 < jnewbery> ok, that's time 10:00 < Kaizen_Kintsugi> dude this was awesome 10:00 < Kaizen_Kintsugi> thanks 10:00 < Kaizen_Kintsugi> learned a lot again today 10:00 < jnewbery> thanks everyone for sticking with this. It was a really hard PR this week 10:01 < pg156> Thank you jnewbery! 10:01 < jnewbery> we'll do something a little easier next time :) 10:01 < Kaizen_Kintsugi> everything that is hard is good for us 10:01 < jnewbery> #endmeeting 10:01 < pg156> I found the git commit log very helpful. Thank you dongcarl for the PR! 10:01 < sm0l> yeah, thanks for another great session 10:01 < gene> thanks for doing these jnewbery 10:01 < lightlike> thanks jnewbery! 10:01 < jnewbery> pg156: I agree! dongcarl write very nice commit logs 10:01 < glozow> thanks for challenging us jnewbery 10:01 < dongcarl> Thank you all for reviewing!! 10:02 < dongcarl> <3 10:02 -!- observer95 [~observer@107.127.60.11] has joined #bitcoin-core-pr-reviews 10:02 < dongcarl> Thanks to jnewbery for hosting! 10:02 -!- sm0l [~sm0l@2a01:799:5f:ec00:670c:fbd9:1c27:c55e] has quit [Quit: Leaving] 10:03 -!- danp [~danp@c-24-22-73-109.hsd1.or.comcast.net] has quit [Client Quit] 10:03 < michaelfolkson> init succeeded 10:03 < seaona> thank you! 10:03 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 10:03 < michaelfolkson> Thanks jnewbery dongcarl etc 10:03 < svav> Hi 10:04 < michaelfolkson> Oops missed it svav 17:00 UTC 10:04 < svav> Oh dear, that's the second time I've done that!! 10:04 -!- Azorcode [~Azorcode@190.74.245.156] has quit [Quit: Connection closed] 10:05 < michaelfolkson> :) 10:05 < dongcarl> svav: There's an ical link somewhere so you can have it on your calendar... 10:05 < dongcarl> Lemme find it for you 10:06 -!- observer95 [~observer@107.127.60.11] has quit [Client Quit] 10:06 < dongcarl> svav: https://bitcoincore.org/en/meetings/ 10:07 < svav> OK thanks 10:07 < svav> Did u have a productive meeting? 10:08 < svav> To be honest, I don't understand a lot of it anyway, partly because I don't run a node yet. 10:08 -!- seaona [~seaona@102.red-83-50-251.dynamicip.rima-tde.net] has quit [Ping timeout: 256 seconds] 10:09 < dongcarl> svav: Yes it was great! Also: you don't absolutely need to run a node to review code! :-) 10:10 < svav> OK cool 10:11 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 10:12 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 10:13 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 10:19 -!- matt50 [~matt@97-122-190-135.hlrn.qwest.net] has quit [Quit: Connection closed] 10:23 -!- RandyMcMillan [~RandyMcMi@47.205.7.87] has quit [Quit: Ping timeout (120 seconds)] 10:26 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has quit [Quit: stickies-v] 10:29 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has joined #bitcoin-core-pr-reviews 10:57 -!- tralfaz [~davterra@143.198.56.186] has quit [Remote host closed the connection] 10:57 -!- tralfaz [~davterra@143.198.56.186] has joined #bitcoin-core-pr-reviews 10:58 -!- nathanael [~nathanael@user/nathanael] has quit [Ping timeout: 240 seconds] 11:01 -!- tralfaz is now known as davterra 11:02 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has quit [Quit: stickies-v] 11:25 < common> shit i always miss meetings lol 11:25 < common> i need to set alarms 11:32 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has joined #bitcoin-core-pr-reviews 11:42 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 11:43 -!- nathanael [~nathanael@user/nathanael] has joined #bitcoin-core-pr-reviews 11:46 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has quit [Quit: stickies-v] 11:58 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene] 12:11 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:27 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 12:27 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 256 seconds] 13:49 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 13:52 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 14:51 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has joined #bitcoin-core-pr-reviews 15:22 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has quit [Quit: stickies-v] 15:25 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has joined #bitcoin-core-pr-reviews 15:26 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 240 seconds] 15:45 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 15:46 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews 15:55 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 15:56 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews 16:23 -!- RubenSomsen [sid301948@user/rubensomsen] has quit [Ping timeout: 245 seconds] 16:24 -!- hugohn [sid304114@lymington.irccloud.com] has quit [Ping timeout: 268 seconds] 16:24 -!- hebasto [sid449604@uxbridge.irccloud.com] has quit [Ping timeout: 260 seconds] 16:24 -!- jkczyz [sid419941@lymington.irccloud.com] has quit [Ping timeout: 244 seconds] 16:24 -!- blkncd [sid505676@helmsley.irccloud.com] has quit [Ping timeout: 260 seconds] 16:24 -!- larryruane [sid473749@uxbridge.irccloud.com] has quit [Ping timeout: 260 seconds] 16:24 -!- fanquake [sid369002@user/fanquake] has quit [Ping timeout: 244 seconds] 16:25 -!- FelixWeis [sid154231@hampstead.irccloud.com] has quit [Ping timeout: 268 seconds] 16:25 -!- amiti [sid373138@lymington.irccloud.com] has quit [Ping timeout: 260 seconds] 16:25 -!- fjahr [sid374480@uxbridge.irccloud.com] has quit [Ping timeout: 260 seconds] 16:26 -!- dergoegge [sid453889@lymington.irccloud.com] has quit [Ping timeout: 268 seconds] 16:27 -!- schmidty [sid297174@id-297174.lymington.irccloud.com] has quit [Ping timeout: 264 seconds] 16:27 -!- lightlike [sid521075@user/lightlike] has quit [Ping timeout: 250 seconds] 16:27 -!- pg156 [sid518209@id-518209.hampstead.irccloud.com] has quit [Read error: Connection reset by peer] 16:27 -!- lsilva_ [sid489830@id-489830.helmsley.irccloud.com] has quit [Read error: Connection reset by peer] 16:27 -!- glozow [sid453516@user/glozow] has quit [Read error: Connection reset by peer] 16:27 -!- ajonas [sid385278@id-385278.helmsley.irccloud.com] has quit [Read error: Connection reset by peer] 16:27 -!- jarolrod [sid475272@id-475272.uxbridge.irccloud.com] has quit [Read error: Connection reset by peer] 16:27 -!- josibake [sid509132@2a03:5180:f:1::7:c4cc] has quit [Read error: Connection reset by peer] 16:27 -!- stick [sid403625@user/prusnak] has quit [Ping timeout: 268 seconds] 16:43 -!- pg156 [sid518209@hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews 16:43 -!- lightlike [sid521075@user/lightlike] has joined #bitcoin-core-pr-reviews 16:44 -!- jarolrod [sid475272@uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews 16:44 -!- schmidty [sid297174@lymington.irccloud.com] has joined #bitcoin-core-pr-reviews 16:45 -!- jkczyz [sid419941@lymington.irccloud.com] has joined #bitcoin-core-pr-reviews 16:48 -!- pg156 [sid518209@hampstead.irccloud.com] has quit [Ping timeout: 256 seconds] 16:49 -!- schmidty [sid297174@lymington.irccloud.com] has quit [Ping timeout: 256 seconds] 16:49 -!- lightlike [sid521075@user/lightlike] has quit [Ping timeout: 256 seconds] 16:49 -!- jarolrod [sid475272@uxbridge.irccloud.com] has quit [Ping timeout: 264 seconds] 16:50 -!- jkczyz [sid419941@lymington.irccloud.com] has quit [Ping timeout: 256 seconds] 16:51 -!- lightlike [sid521075@user/lightlike] has joined #bitcoin-core-pr-reviews 16:52 -!- pg156 [sid518209@hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews 16:52 -!- schmidty [sid297174@lymington.irccloud.com] has joined #bitcoin-core-pr-reviews 16:53 -!- jarolrod [sid475272@uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews 16:54 -!- josibake [sid509132@helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews 16:54 -!- lsilva_ [sid489830@helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews 16:54 -!- glozow [sid453516@user/glozow] has joined #bitcoin-core-pr-reviews 17:00 -!- RubenSomsen [sid301948@user/rubensomsen] has joined #bitcoin-core-pr-reviews 17:00 -!- amiti [sid373138@lymington.irccloud.com] has joined #bitcoin-core-pr-reviews 17:00 -!- FelixWeis [sid154231@hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews 17:01 -!- fjahr [sid374480@uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews 17:01 -!- hebasto [sid449604@uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews 17:01 -!- larryruane [sid473749@uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews 17:01 -!- blkncd [sid505676@helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews 17:01 -!- dergoegge [sid453889@lymington.irccloud.com] has joined #bitcoin-core-pr-reviews 17:03 -!- jkczyz [sid419941@lymington.irccloud.com] has joined #bitcoin-core-pr-reviews 17:11 -!- hugohn [sid304114@lymington.irccloud.com] has joined #bitcoin-core-pr-reviews 17:11 -!- fanquake [sid369002@user/fanquake] has joined #bitcoin-core-pr-reviews 17:11 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has quit [Quit: stickies-v] 17:13 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has joined #bitcoin-core-pr-reviews 17:14 -!- ajonas [sid385278@helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews 17:24 -!- stick [sid403625@user/prusnak] has joined #bitcoin-core-pr-reviews 17:29 -!- stickies-v [~textual@host-92-12-111-116.as13285.net] has quit [Ping timeout: 240 seconds] 17:45 -!- MaxDoronin [~MaxDoroni@host81-146-62-223.range81-146.btcentralplus.com] has quit [Ping timeout: 256 seconds] 23:37 -!- blkncd [sid505676@helmsley.irccloud.com] has quit [Ping timeout: 256 seconds] 23:40 -!- blkncd [sid505676@id-505676.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews --- Log closed Thu Nov 11 00:00:29 2021