--- Log opened Wed Mar 05 00:00:36 2025
01:15 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
01:45 -!- rkrux [~rkrux@user/rkrux] has joined #bitcoin-core-pr-reviews
02:06 -!- pyth [~pyth@user/pyth] has quit [Remote host closed the connection]
02:14 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
02:15 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 264 seconds]
02:57 -!- rkrux [~rkrux@user/rkrux] has quit [Quit: Client closed]
02:59 -!- Musa [~Musa@102.90.46.131] has joined #bitcoin-core-pr-reviews
03:01 -!- Musa [~Musa@102.90.46.131] has quit [Client Quit]
05:15 -!- davesoma [~davesoma@178.197.215.148] has joined #bitcoin-core-pr-reviews
05:25 -!- davesoma [~davesoma@178.197.215.148] has quit [Ping timeout: 240 seconds]
05:27 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1001] has quit [Read error: Connection reset by peer]
05:27 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1001] has joined #bitcoin-core-pr-reviews
06:01 -!- rkrux [~rkrux@user/rkrux] has joined #bitcoin-core-pr-reviews
06:56 -!- rkrux [~rkrux@user/rkrux] has quit [Quit: Client closed]
08:07 -!- jtraub91 [~jason@2603:8080:1500:4366:c625:8c47:8029:f1e0] has joined #bitcoin-core-pr-reviews
08:14 -!- stringintech [~stringint@2602:fa59:3:774::1] has joined #bitcoin-core-pr-reviews
08:17 -!- davesoma [~davesoma@178.197.211.88] has joined #bitcoin-core-pr-reviews
08:21 -!- stringintech [~stringint@2602:fa59:3:774::1] has quit [Ping timeout: 240 seconds]
08:26 -!- davesoma [~davesoma@178.197.211.88] has quit [Ping timeout: 240 seconds]
08:34 -!- davesoma [~davesoma@178.197.211.88] has joined #bitcoin-core-pr-reviews
08:39 -!- stringintech [~stringint@2602:fa59:3:774::1] has joined #bitcoin-core-pr-reviews
08:40 -!- janb84 [arjan@user/janb84] has joined #bitcoin-core-pr-reviews
08:43 -!- davesoma [~davesoma@178.197.211.88] has quit [Ping timeout: 240 seconds]
08:50 -!- strat___ [uid514069@id-514069.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
08:56 -!- janb84 [arjan@user/janb84] has quit [Quit: WeeChat 4.4.3]
08:56 -!- davesoma [~davesoma@178.197.211.88] has joined #bitcoin-core-pr-reviews
08:57 -!- Emc99 [~Emc99@212.129.75.106] has joined #bitcoin-core-pr-reviews
08:58 -!- pablomartin [~pablomart@46.183.111.107] has joined #bitcoin-core-pr-reviews
08:59 -!- Devgitotox [~Devgitoto@105.163.2.242] has joined #bitcoin-core-pr-reviews
09:00 < stickies-v> #startmeeting
09:00 < marcofleon> hi
09:00 < stringintech> Hi!
09:00 < lightlike> hi
09:00 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:00 < Devgitotox> hi
09:00 < strat___> hi
09:00 < monlovesmango> hello
09:01 < stickies-v> hi everyone, thanks for a lot for joining in on this validation review club
09:01 < stickies-v> and great to have author lightlike here too!
09:01 < marcofleon> woo!
09:02 < stickies-v> today we're looking at #31405, with notes and questions available at https://bitcoincore.reviews/31405
09:02 < stickies-v> anyone joining us for the first time today? even if you're just lurking, feel free to say hi!
09:02 < Devgitotox> me
09:02 < Devgitotox> first time
09:02 < davesoma> me too
09:02 < monlovesmango> welcome :)
09:03 < stickies-v> nice one, glad you found your way Devgitotox and davesoma . the conversation is async,  so feel free to pop your questions at any time!
09:03 -!- Jelle51 [~Jelle@77-173-156-15.fixed.kpn.net] has joined #bitcoin-core-pr-reviews
09:03 < stickies-v> who got the chance to review the PR or read the notes? (y/n)
09:03 -!- adys [~adys@2a06:c701:cb45:ae00:7707:4c6b:40c5:59fe] has joined #bitcoin-core-pr-reviews
09:03 < Emc99> I did
09:04 < strat___> yes
09:04 < marcofleon> yes, light review
09:04 < Jelle51> I didnt. It's my first time around
09:04 < monlovesmango> read the notes but only lite pr review
09:04 -!- catnip [~catnip@92.19.47.23] has joined #bitcoin-core-pr-reviews
09:05 < stickies-v> cool, welcome to review club Jelle51 ! feel free to lurk or chime in whenever you want to
09:05 < stringintech> I looked at the changes but found out about the notes not soon enough. (Not sure I missed them or they were not uploaded when I looked at the PR)
09:05 < Jelle51> Thanks
09:05 -!- Larry [~Larry@c-73-229-3-236.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews
09:05 < stickies-v> strat___ already left a nice ACK on the PR, but for everyone else able to review: would you give it a Concept ACK, Approach ACK, Tested ACK, or NACK? what was your review approach?
09:06 < stickies-v> stringintech: that's my bad, I only finished them Monday evening despite our week-in-advance hosting guideline :( sorry!
09:07 < marcofleon> Concept ACK I'd say. I think makes sense to have these values be set correctly instead of estimated. The PR descriptions makes a good case for it
09:07 < stringintech> :stickies-v No worries! actually it turned out to be kind of better for me cause I had to think harder I guess :))
09:07 < glozow> hi
09:07 < marcofleon> but personally would have to give more time to understanding about the surrounding validation code in general
09:08 < stickies-v> marcofleon: yeah! the rationale seems pretty straightforward, but assessing the actual code changes is a bit more involved
09:08 < stickies-v> i think we can definitely talk more about rationale and general understanding in this PR, i too have quite a bit of outstanding questions so hopefully we can all learn together
09:09 < stickies-v> let's get started with the first conceptual questions
09:09 < stickies-v> 1. Which purpose(s) does `ChainstateManager::m_best_header` serve?
09:09 < stringintech> Concept ACK. Almost everything was new to me though so I had to spend some time to grasp the context a bit. I also wrote some small integration test (python test framework) to understand the behaviour in some cases.
09:11 < monlovesmango> tracks the header with the most work that may or may not be invalid (since we may not have all the blocks to validate yet)
09:11 < marcofleon> m_best_header points to the most PoW chain, even if it hasn't been validated yet
09:11 < stickies-v> oh that's a great approach stringintech, perhaps they're worth sharing on the PR too for other people's understanding and/or adding them to the codebase?
09:11 < strat___> it's the best block header we've seen so far (not known to be invalid)
09:11 < catnip>  @xgclass introduced to manage one or more CChainState objects, which track the state of the blockchain (e.g., the UTXO set and the active chain of blocks
09:12 < stringintech> :stickies-v I doubt they could be added to the codebase (not clean/comprehensive enough) but I will definitely check if I can share them as learning material on the PR page.
09:13 < stickies-v> monlovesmango: marcofleon strat___ yes! with the nuance of "not known to be invalid" as strat___ correctly pointed out
09:14 < stickies-v> and what are some important use cases for this member? i.e., if it's not always correct, why do we even have it in the first place?
09:14 < lightlike> I think of it as the header for the block we would like our chain to move to (by downloading missing block data, doing validation etc.) - which may work out or not.
09:14 < monlovesmango> IBD is the main one right?
09:14 < stickies-v> catnip: i think you might be talking about the ChainstateManager more generally, instead of just its `m_best_header` member?
09:15 < stringintech> stickies-v: I guess it helps us to see where we wanna go / what blocks to sync next
09:15 < stringintech> for the best/active chain
09:15 < strat___> m_best_header is displayed by getblockchaininfo()['bestblockhash']
09:15 < strat___> active chain tip is displayed by getbestblockhash
09:15 < strat___> (the PR notes explains the difference well but just wanted to mention a way to see the effects!)
09:16 < stickies-v> lightlike: yeah, kinda like a north start (that might turn out to have died millions of years ago when the light/block data finally reaches us)
09:16 < marcofleon> very poetic
09:16 < monlovesmango> good analogy hahah
09:17 < stickies-v> stringintech: stringintech: yep! there are some other use cases too
09:18 < stickies-v> for example, it also seems like it's used as a proxy for current time, e.g. to determine if a block is old enough to qualify as historic (which in turn affects how much we'll serve it to peers etc)
09:19 < stringintech> Interesting!
09:19 < lightlike> monlovesmango: You could imagine that (and I think it could've been implemented that way), but I if I remember correctly I think It's actually not being used during IBD to determine which blocks to download next - but it is for related things such as whether to apply -assumevalid (i.e. skip script validation) or not.
09:19 -!- Guest59 [~Guest59@2804:30c:c76:1f00:3071:cb45:2d2d:c2e2] has joined #bitcoin-core-pr-reviews
09:19 < stickies-v> as lightlike pointed out on a previous PR, bluematt also listed out most use cases on a ~6yo PR: https://github.com/bitcoin/bitcoin/pull/16974 - that's pretty interesting to read!
09:20 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:20 < strat___> where is the proxy for current time part?
09:20 < monlovesmango> lightlike: interesting thank you
09:21 < stickies-v> lightlike: it is used when we receive unconnecting headers (in `HandleUnconnectingHeaders()`), to determine which headers to request from our peer, but I'm not sure if that function is actually reached in IBD? didn't look into that
09:22 < stickies-v> strat___: in `BlockRequestAllowed()` and `ProcessGetBlockData()`, for example
09:22 < lightlike> stickies-v: good point, yes, that should be reachable in IBD.
09:23 < stickies-v> I'm going to launch the next question already, but as always, feel free to continue the discussion on previous topics if there's anything else you find
09:23 < stickies-v> 2. Prior to this PR, which of these statements are true, if any? 
09:23 < stickies-v> A) a `CBlockIndex` with an INVALID predecessor will ALWAYS have a `BLOCK_FAILED_CHILD` `nStatus`
09:24 < stickies-v> B) a `CBlockIndex` with only VALID predecessors will NEVER have a `BLOCK_FAILED_CHILD` `nStatus`
09:24 -!- luisfg30 [~luisfg30@user/luisfg30] has joined #bitcoin-core-pr-reviews
09:25 -!- Musa [~Musa@102.91.29.44] has joined #bitcoin-core-pr-reviews
09:25 -!- Musa [~Musa@102.91.29.44] has quit [Client Quit]
09:25 < marcofleon> I wanna say false for A but not entirely sure. I think in AcceptBlockHeader we do walk back along the block tree and mark blocks with `BLOCK_FAILED_CHILD`?
09:25 < monlovesmango> I think B is true
09:25 < stringintech> A- false (the PR fixes that)
09:25 < stringintech> B- true (not sure though; can we change our mind on a previously invalid parent?)
09:25 -!- Musa [~Musa@102.91.29.44] has joined #bitcoin-core-pr-reviews
09:26 < catnip> Orphans?
09:26 < marcofleon> but yeah the PR is addressing A it seems. Where in the code can it be missed?
09:26 < catnip> @stickies-v orphans?
09:26 < stickies-v> stringintech: there's a "reconsiderblock" RPC which serves as a counterpart to "invalidateblock"
09:26 < marcofleon> BLOCK_MUTATED maybe?
09:27 < stickies-v> and stringintech: yes you're correct about A), that's one of the goals of this PR
09:28 < strat___> A is false - before this PR - only in the active chain we were supposed to mark children as BLOCK_FAILED_CHILD (there is an incorrect traversal
09:28 < strat___> which #31835 fixes). other blocks in the block index which descend from BLOCK_FAILED_VALID were not marked as invalid. and this PR fixes that.
09:29 < stringintech> :stickies-v Oh. I have not seen "reconsiderblock". But perhaps if we reconsider a parent block (and it becomes valid) its descendant could become valid too.
09:29 < lightlike> "invalidateblock" and "reconsiderblock" make these kind of changes more complicated, because they are kind of artificial: Normally, a block that was once completely validated will be valid forever, "invalidateblock" changes that assumption it's basically the user overruling: "this block is invalid because I say so".
09:29 < stickies-v> monlovesmango: what about this scenario: B is a child of A, and B is in the active chain when A gets invalidated. Then, the node receives a B' (with higher cumulative work than B), also building on A. Then we make A valid again with `reconsiderblock()`. Does it still hold?
09:30 < strat___> :lightlike +1, B is true in world without invalidateblock, reconsiderblock powers. but false if we have the powers :)
09:30 -!- davesoma [~davesoma@178.197.211.88] has quit [Quit: Client closed]
09:32 -!- Guest59 [~Guest59@2804:30c:c76:1f00:3071:cb45:2d2d:c2e2] has quit [Ping timeout: 240 seconds]
09:32 < stickies-v> strat___: lightlike: well, actually, I think B holds true even with `reconsiderblock` (and the scenario I outlined), because `reconsiderblock` does nicely walk all the descendants of the reconsider block
09:33 < strat___> https://usercontent.irccloud-cdn.com/file/fh2i10iu/pic.png
09:34 < stickies-v> so my understanding is A) is clearly false (as per the PR), but i've not found a scenario to falsify B)
09:34 < stickies-v> strat___: if you reconsiderblock @height=2, how would that suddenly make it valid if its parent is BLOCK_FAILED_VALID?
09:34 < marcofleon> strat___: that's a nice diagram
09:34 < strat___> stickies-v: is the scenario in the pic what you described or is it another scenario?
09:35 < lightlike> A used to be true in even more cases, my previous PR from last summer https://github.com/bitcoin/bitcoin/pull/30666 already fixed some of them (but not all) - so this PR fixes the remaining ones so that we can add the assumptions to CheckBlockIndex().
09:35 < stickies-v> strat___: almost - in my scenario we reconsiderblock @height=1
09:35 -!- Musa [~Musa@102.91.29.44] has quit [Quit: Client closed]
09:35 < monlovesmango> stickies-v: Interesting scenario. if B is immediately invalidated then maybe (but i think this PR is what would guarantee B is immediately invalidated). B' should be reconsidered when reconsidering A..?
09:35 < stickies-v> (lightlike: did yo mean "false" in even more cases?)
09:35 < strat___> stickies-v: because reconsiderblock traverses all ancestors and descendants in a linear fashion. but not the entire block index.
09:35 < lightlike> stickies-v: oops, yes!
09:36 < stringintech> :stickies-v Regarding your the last scenario, you mean that invalidated blocks through invalidate RPC may not remain invalid forever? (makes sense to me just wanted to make sure)
09:36 < monlovesmango> prior to this pr, when A gets invalidated would B also immediately be invalidated?
09:36 < stickies-v> strat___: mmm, I think it does traverse the entire block index? https://github.com/bitcoin/bitcoin/blob/bd0ee07310c3dcdd08633c69eac330e2e567b235/src/validation.cpp#L3841
09:37 < strat___> but there's an if guard which checks if you are a descendant and only then you enter the BLOCK_FAILED_VALID clearing part
09:37 < stickies-v> monlovesmango: yes indeed, and B` would be reconsidered! but the "gotcha" here could be that B is now no longer in the most-pow chain, so it wouldn't get reconnected, so we need to check that there's some other process to update its validity flags
09:37 < catnip> stickies-v  would that mean a chain reorg?
09:38 -!- Musa [~Musa@102.91.29.44] has joined #bitcoin-core-pr-reviews
09:38 < strat___> similarly there's an if condition few lines below which checks if you're an ancestor and then clears BLOCK_FAILED_MASK
09:41 < stickies-v> yes sorry you're right we only consider ancestors and descendants, i meant that we traverse the entire block index to find them but that's not super relevant
09:41 < monlovesmango> yes I suppose so! just to check my understanding, prior to this PR would B get stuck with a valid status (since child blocks aren't invalidated immediately)?
09:42 < stickies-v> monlovesmango: that's a good question!
09:43 < stickies-v> my understanding is that yes it would, until it's fixed in https://github.com/bitcoin/bitcoin/pull/31405/commits/e32df45a62e6999b12d035758c9c6bd4994ea682
09:43 < stickies-v> 3. One of the goals of this PR is to ensure `m_best_header`, and the `nStatus` of successors of an invalid block are always correctly set. Which functions are directly responsible for updating these values?
09:44 < stickies-v> catnip: would what mean a chain reorg, exactly?
09:45 < stringintech> SetBlockFailureFlags (for nStatus), RecalculateBestHeader (for best header), and InvalidateBlock (both)? (if we are considering those who change the values directly)
09:46 < stickies-v> stringintech: exactly! `InvalidateBlock`implements its own best header calculation, which is a good segue into the next question
09:46 < stickies-v> 5. Most of the logic in commit [validation: in invalidateblock, calculate m_best_header right away](https://github.com/bitcoin-core-review-club/bitcoin/commit/4100495125e9a06b2403f7520fae9f45c3fd9e4c) implements finding the new best header. What prevents us from just using `RecalculateBestHeader()` here?
09:47 < stringintech> You mean just replacing the PR logic with RecalculateBestHeader or call RecalculateBestHeader after disconnecting all the blocks?
09:48 < marcofleon> is it because we want to avoid traversing the block index?
09:49 < marcofleon> so we use `best_header_blocks_by_work` instead?
09:49 < stickies-v> stringintech: sorry, I mean pretty much replacing ~these lines (https://github.com/bitcoin/bitcoin/pull/31405/commits/4100495125e9a06b2403f7520fae9f45c3fd9e4c#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98R3777-R3788) with a `RecalculateBestHeader()` call
09:49 < catnip> m_best_header` points to a valid tip and goes back to genesis?
09:49 < monlovesmango> is it the lock on cs_main?
09:49 -!- pablomartin [~pablomart@46.183.111.107] has quit [Ping timeout: 252 seconds]
09:50 < stringintech> Ahaa, so as marcofleon: already mentioned, it wouldn't make sense to traverse the whole block index with each block-disconnect
09:50 < lightlike> stringintech: these are the non-normal cases for invalid block edge cases. I'd say the most important spot where m_best_header  is set is AddToBlockIndex() in blockmanager when a new block index is received. 
09:51 < lightlike> (referring to question 3 still)
09:51 < stickies-v> catnip: there are no guarantees that m_best_header is a valid block, it's a best effort attempt, but yes you can traverse back to genesis from there
09:52 < stickies-v> monlovesmango: can you elaborate? do you mean one approach is holding a lock while the other isn't?
09:52 < catnip> race conditions on csmain with lock?
09:52 < stringintech> lightlike: Oh right. I will look into it. Thanks.
09:53 < monlovesmango> I misread the RecalculateBestHeader function, it only asserting that lock is held, not trying to create a new lock
09:54 < stickies-v> marcofleon: stringintech: yeah , my understanding for Q5 is that it's an optimization to avoid unnecessarily traversing `m_block_index` - lightlike do you have anything to add there? we talked about this offline a bit
09:54 < stickies-v> catnip: what do you mean?
09:55 < stickies-v> we're almost out of time - quick poll - would people prefer we cover Q7 or Q8? otherwise i pick
09:56 < lightlike> stickies-v: yes, exactly. The idea is to traverse m_block_index only once, not multiple times (imagine someone invalidateblock for a lot of blocks, which is already quite slow)
09:56 < strat___> (old question - understood the scenario now) catnip: stickies-v:  A - B' becomes the active chain now. maybe that's the reorg you're referring to.  https://usercontent.irccloud-cdn.com/file/u0RCF8KU/pic-2.png
09:56 < monlovesmango> you choose
09:56 < marcofleon> stickies-v: you pick
09:56 < stickies-v> 8. Would we still need the  `cand_invalid_descendants` cache if we were able to iterate forwards (i.e. away from the genesis block) over the block tree? What would be the pros and cons of such an approach, compared to the one taken in this PR?
09:58 < stickies-v> strat___: yes!! thank you for making a diagram, that's so much more helpful. So my concern (which turned out to be unfounded) was that because B was no longer in active chain, it wouldn't get connected again, and so its status might not get updated (but `reconnectblock` does indeed handle it well)
09:58 < stringintech> We wouldn't need it if we had pointers to all children of a block I guess (which is impractical to maintain).
09:58 < catnip> temp cache for invalid descendants
09:59 < monlovesmango> I don't think so. the cons would be there would be a whole new data structure to maintain on CBlockIndex (and it would be more complex than the pprev pointer as you can multiple decendants)
09:59 -!- instagibbs [~instagibb@pool-100-15-116-202.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:59 < stickies-v> stringintech: what makes it impractical?
10:00 < stringintech> maybe complexity in the design? and always maintaining a correct list of children?
10:00 < stickies-v> monlovesmango: it would just be a simpler container of pointers, like a `std::vector<CBlockIndex*>`. and since we never remove items from `m_block_index`, we'd only have to add a pointer to a predecessor once, and then never look at it again
10:00 < stringintech> I was also gonna say storage... but maybe not :)
10:00 < marcofleon> we'd have to be able to point to multiple children
10:00 < stickies-v> s/it would/it could
10:01 < lightlike> also  all block indexes are constantly held in memory, so it adds up the longer the chain gets (testnet 3 has 4M blocks now...).
10:01 < stickies-v> stringintech: we wouldn't have to persist this to storage, can be calculated whenever we load from disk
10:02 -!- janb84 [janb84@user/janb84] has joined #bitcoin-core-pr-reviews
10:02 < monlovesmango> the pro might be that it could be useful for other things
10:02 < stringintech> :stickies-v Oh; You are right.
10:02 < monlovesmango> stickies-v: you make it sound simple haha. but agree.
10:02 < stickies-v> lightlike: yeah , it would mean a lot of additional vectors and pointers in memory
10:03 < catnip> stickies-v  Cons: memory usage ? Redundant trees walking through?
10:03 -!- Emc99 [~Emc99@212.129.75.106] has quit [Quit: Client closed]
10:03 < monlovesmango> I guess my assumption was that this is unwanted overhead which is why it hasn't been done
10:03 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
10:03 < stickies-v> catnip: yes! iterating backwards is trivial, because each block has 1 parent. But iterating forward, even if we explicitly link the block indexes, would still be non-trivial because we have to cover all branches
10:04 < stickies-v> there aren't really any performance implications, because this is a pretty rare code path
10:04 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Client Quit]
10:04 -!- Devgitotox [~Devgitoto@105.163.2.242] has quit [Quit: Client closed]
10:04 < stickies-v> and i'm not sure it would meaningfully simplify the code (but i'd love to be proven wrong if anyone wants to prototype it)
10:05 < stickies-v> monlovesmango: yes to both your points!
10:05 < stickies-v> alright, went a bit over time already, thank you everyone for your participation on today's review club, and lightlike for making variables less wrong, yay!
10:05 < catnip> stickies-v -_-
10:05 < marcofleon> thanks stickies, good stuff
10:06 < lightlike> thank you stickies-v!
10:06 < monlovesmango> thank you stickies-v! great review session :)
10:06 < catnip> Merci
10:06 < stringintech> Thank you all!
10:06 < stickies-v> i'll be on here for another ~15 minutes, if anyone has general conceptual questions on the block validation touched by this PR
10:06 < strat___> thank you stickies-v for hosting!
10:06 < stickies-v> so feel free to shoot questions, concerns, ideas, if you still have them
10:06 < stickies-v> #endmeeting
10:07 -!- catnip [~catnip@92.19.47.23] has quit [Quit: Client closed]
10:07 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
10:08 < monlovesmango> exit
10:08 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Quit: leaving]
10:09 -!- Musa [~Musa@102.91.29.44] has quit [Quit: Client closed]
10:13 -!- janb84 [janb84@user/janb84] has left #bitcoin-core-pr-reviews []
10:17 < stickies-v> oh and thank you strat___ for being the diagram supplier!
10:20 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:21 -!- stringintech [~stringint@2602:fa59:3:774::1] has quit [Quit: Client closed]
10:23 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
10:28 -!- adys [~adys@2a06:c701:cb45:ae00:7707:4c6b:40c5:59fe] has quit [Quit: Client closed]
10:41 -!- luisfg30 [~luisfg30@user/luisfg30] has left #bitcoin-core-pr-reviews []
11:45 -!- sdmg15 [~sdmg15@129.0.103.4] has joined #bitcoin-core-pr-reviews
11:48 -!- sdmg15 [~sdmg15@129.0.103.4] has quit [Client Quit]
11:56 -!- Larry [~Larry@c-73-229-3-236.hsd1.co.comcast.net] has quit [Remote host closed the connection]
11:57 -!- Larry [~Larry@c-73-229-3-236.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews
12:01 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
12:08 -!- strat___ [uid514069@id-514069.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:12 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
12:22 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:49 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:36 -!- Larry [~Larry@c-73-229-3-236.hsd1.co.comcast.net] has quit [Remote host closed the connection]
13:56 -!- Jelle51 [~Jelle@77-173-156-15.fixed.kpn.net] has quit [Quit: Client closed]
14:04 -!- hernanmarino [~hernanmar@181.85.42.119] has quit [Ping timeout: 265 seconds]
14:04 -!- hernanmarino_ [~hernanmar@2800:2330:2800:28a:bd60:a019:f2a2:d46e] has joined #bitcoin-core-pr-reviews
14:32 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
15:20 -!- hernanmarino_ [~hernanmar@2800:2330:2800:28a:bd60:a019:f2a2:d46e] has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
15:20 -!- hernanmarino [~hernanmar@2800:2330:2800:28a:bd60:a019:f2a2:d46e] has joined #bitcoin-core-pr-reviews
15:30 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
16:24 -!- pablomartin [~pablomart@46.183.111.102] has joined #bitcoin-core-pr-reviews
16:29 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
16:48 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
17:01 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
17:21 -!- Anu [anunay@user/anunay] has joined #bitcoin-core-pr-reviews
17:24 -!- pablomartin [~pablomart@46.183.111.102] has quit [Remote host closed the connection]
17:25 -!- pablomartin [~pablomart@46.183.111.102] has joined #bitcoin-core-pr-reviews
17:25 -!- pablomartin [~pablomart@46.183.111.102] has quit [Remote host closed the connection]
18:31 -!- pyth [~pyth@user/pyth] has quit [Remote host closed the connection]
19:16 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
19:17 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
19:19 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
19:56 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
20:41 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
20:49 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
22:16 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
23:29 -!- jtraub91 [~jason@2603:8080:1500:4366:c625:8c47:8029:f1e0] has quit [Quit: WeeChat 4.5.1]
23:48 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
23:57 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
--- Log closed Thu Mar 06 00:00:37 2025