--- Log opened Wed May 14 00:00:43 2025
00:18 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
00:20 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 265 seconds]
00:20 -!- PaperSword1 is now known as PaperSword
00:58 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
01:03 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 245 seconds]
01:26 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
01:29 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
01:31 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 276 seconds]
01:34 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
01:47 -!- TheCharlatan [~drgrid@2a01:4f8:c013:ed0b::1] has joined #bitcoin-core-pr-reviews
02:13 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
02:15 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
02:16 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-pr-reviews
03:26 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
03:30 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
03:34 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
03:40 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
03:45 -!- PaperSword1 [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
03:46 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 244 seconds]
03:46 -!- PaperSword1 is now known as PaperSword
03:59 -!- Holz_ [~Holz@user/Holz] has quit [Ping timeout: 244 seconds]
04:51 -!- Holz [~Holz@user/Holz] has joined #bitcoin-core-pr-reviews
05:08 -!- brunoerg [~brunoerg@2804:14d:5285:8318:658c:4bd4:bb3e:dfdb] has quit [Remote host closed the connection]
05:40 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
05:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has joined #bitcoin-core-pr-reviews
05:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has quit [Ping timeout: 260 seconds]
06:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has joined #bitcoin-core-pr-reviews
06:17 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
06:18 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 260 seconds]
06:18 -!- PaperSword1 is now known as PaperSword
06:21 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
06:26 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 245 seconds]
06:36 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
06:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has quit [Remote host closed the connection]
06:46 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
06:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has joined #bitcoin-core-pr-reviews
06:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has quit [Remote host closed the connection]
06:50 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 252 seconds]
07:04 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
07:04 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
07:06 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
07:15 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
07:15 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Read error: Connection reset by peer]
07:16 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
07:18 -!- Davidson [~erik@vmi1165796.contaboserver.net] has joined #bitcoin-core-pr-reviews
07:28 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
07:32 -!- brunoerg [~brunoerg@2804:14d:5285:8318:d4e4:cda8:a7c:8076] has joined #bitcoin-core-pr-reviews
07:33 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
07:41 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has quit []
07:58 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-pr-reviews
09:00 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
09:05 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 248 seconds]
09:06 -!- davesoma [~davesoma@2a02:1210:621d:e200:65d2:549f:bf2d:44d3] has joined #bitcoin-core-pr-reviews
09:09 -!- pablomartin_ [~pablomart@217.130.254.81] has joined #bitcoin-core-pr-reviews
09:12 -!- davesoma [~davesoma@2a02:1210:621d:e200:65d2:549f:bf2d:44d3] has quit [Quit: Client closed]
09:19 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
09:24 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
09:26 -!- pyth [~pyth@user/pyth] has quit [Quit: Leaving]
09:42 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
09:45 -!- pablomartin_ [~pablomart@217.130.254.81] has quit [Ping timeout: 244 seconds]
09:45 -!- pablomartin_ [~pablomart@217.130.254.81] has joined #bitcoin-core-pr-reviews
09:49 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
09:50 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 252 seconds]
09:56 -!- JoaoLeal [~JoaoLeal@2804:1b3:a8c3:22b7:502b:aeff:fe4e:a5da] has joined #bitcoin-core-pr-reviews
09:57 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
09:59 -!- stringintech [~stringint@2602:fa59:3:451::1] has joined #bitcoin-core-pr-reviews
09:59 -!- enochazariah [~enochazar@162.245.239.130] has joined #bitcoin-core-pr-reviews
09:59 -!- monlovesmango [~monlovesm@146.70.72.141] has joined #bitcoin-core-pr-reviews
10:00 < stickies-v> #startmeeting
10:00 < corebot> stickies-v: Meeting started at 2025-05-14T17:00+0000
10:00 < corebot> stickies-v: Current chairs: stickies-v
10:00 < corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
10:00 < corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
10:00 < corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
10:00 < stickies-v> hey everyone, welcome to the review club!
10:00 < stringintech> Hi!
10:00 < brunoerg> hi
10:00 < Davidson> Hi
10:00 < monlovesmango> hey
10:00 < marcofleon> yo
10:00 < JoaoLeal> Hi
10:00 < stickies-v> today we'll be covering https://bitcoincore.reviews/32317, titled "Separate UTXO set access from validation functions"
10:01 < enochazariah> hello
10:01 < marcofleon> woo!
10:01 < stickies-v> is anyone here for the first time? feel free to say hi, even if you're just lurking
10:01 < TheCharlatan> hello!
10:01 < Davidson> stickies-v: I haven't participated in a while. Ho hi :)
10:01 < Davidson> so*
10:02 < lightlike> hi
10:02 < pablomartin_> hello
10:02 < stickies-v> well, welcome back Davidson! are you the floresta davidson, by any chance?
10:02 < Davidson> Yeap, it's me
10:03 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 272 seconds]
10:03 < stickies-v> oh nice, we've got kernel users, contributors, reviewers and enthusiasts all in one meeting!
10:03 < stickies-v> (reviewing IS contributing, of course)
10:03 < stickies-v> did anyone get the chance to review the notes and/or PR (y/n)?
10:04 < Davidson> y
10:04 < stringintech> y
10:04 < marcofleon> y, checked out the notes and an initial code review of the PR
10:04 < brunoerg> yes
10:04 < monlovesmango> yes
10:04 < enochazariah> yes, checked the code out
10:04 < TheCharlatan> y :D
10:05 < stickies-v> oh my that's a lot of prep, excellent
10:05 < stickies-v> let's dive right into the questions, we'll start off with the more conceptual ones and then progress into code questions. as always, review club is async so feel free to continue conversation on previous questions when we move on, or raise any other questions you have!
10:06 < stickies-v> 2. Why is carving out the new SpendBlock() function from ConnectBlock() helpful for this PR? How would you compare the purpose of the two functions?
10:08 < monlovesmango> it will remove all UTXO set interactions from ConnectBlock which makes ConnectBlock much more modular. SpendBlock encapsulates all the UTXO interactions that are needed when connecting new block
10:09 < marcofleon> carving it out is helpful because using ConnectBlock no longer requires the utxo set. So you can do a lot of block validation without a utxo set
10:09 < Davidson> Before this PR, ConnectBlock also looked utxos up, and therefore needed access to the utxo set. Now, the feching of utxos is defered to the new function. Making ConnectBlock work without access to the utxo set
10:10 < stickies-v> right, not every full node implementation has a UTXO set, so only being able to connect a block by passing UTXO set as a parameter seems rather opinionated for how Core works
10:11 < stickies-v> follow-up question: does the new ConnectBlock allow for stateless validation?
10:12 < marcofleon> do you count blockundo as non-state? if that makes sense
10:12 < monlovesmango> yes..? what does stateless validation mean? not needing the statefulness of utxo set?
10:12 < marcofleon> i guess the new Connectblock would still requite some state then?
10:13 < marcofleon> but it's prevalidated by SpendBlock
10:13 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:13 < stickies-v> blockundo is a ConnectBlock parameter, so that does not count as state
10:14 < stringintech> I guess using the fJustCheck as true could do this for us?
10:14 < Davidson> I would say no. Because it still uses a ref to the block tree index.
10:14 < monlovesmango> ah ok, so stateless validation would be any state that is not passed in by parameters?
10:15 < stickies-v> what I'm trying to get at is: if someone has a serialized block, and they want to check if it's valid, can they validate it with a function (similar to) ConnectBlock?
10:15 < stickies-v> so state in this case would be from the Chainstate instance of which ConnectBlock is a method
10:17 < TheCharlatan> there is still extra state require, for example they still need the deployment bits
10:18 < marcofleon> those pesky deployment bits
10:18 < stickies-v> Davidson: yeah ConnectBlock has side-effects (as clearly implied by the name too) in that it e.g. updates the chainstate, and the block index
10:19 < marcofleon> i thought SpendBlock updates the chainstate?
10:20 < marcofleon> unless i'm mistaking what the chainstate is here...
10:20 < stickies-v> oh sorry yes that's confusing naming 🙈
10:22 < TheCharlatan> I guess you meant members of the Chainstate class?
10:23 < stickies-v> i was thinking about connecting the block to the chaintip (i.e. state of the Chain) but now i'm not actually sure if that's ahppening in ConnectBlock
10:24 < stickies-v> you're right marcofleon that ConnectBlock does not update the UTXO set, commonly called the chainstate
10:25 < TheCharlatan> ah, yes, that is moved out of ConnectBlock in the commit "    validation: Move SetBestBlock out of ConnectBlocky
10:25 < stickies-v> ah right!
10:26 < stickies-v> 3. 3. Do you see another benefit of this decoupling, besides allowing kernel usage without a UTXO set?
10:26 -!- pablomartin_ [~pablomart@217.130.254.81] has quit [Ping timeout: 248 seconds]
10:27 < marcofleon> maybe easier testing
10:27 < Davidson> I would say it's cleaner. Since you have a clear separation of concerns
10:27 < enochazariah> i see modularity as another benefit of decoupling
10:27 < marcofleon> by splitting up parts of validation into separate functions
10:27 -!- pablomartin_ [~pablomart@217.130.254.81] has joined #bitcoin-core-pr-reviews
10:28 < stickies-v> yeah improved testability was the main benefit i was thinking of, reusability/modularity might be a win too even though the potential there is probably a bit more limited since there's only so many places these functions can be used
10:28 < monlovesmango> it also helps with code maintainability as there is separation of concerns
10:28 -!- JoaoLeal [~JoaoLeal@2804:1b3:a8c3:22b7:502b:aeff:fe4e:a5da] has quit [Ping timeout: 240 seconds]
10:28 < stickies-v> anything else?
10:29 < Davidson> Makes it easier to validate blocks in parallel (e.g. swift-sync)
10:30 < stickies-v> yes! but isn't that a direct effect of the "allowing kernel usage without a UTXO set" bit?
10:30 < Davidson> yeah, I think so
10:31 < stickies-v> TheCharlatan observed a few other minor improvements:
10:32 < stickies-v> reducing the amount of UTXO set lookups (by just doing it once at the beginning) can have minimal performance improvements
10:33 < stickies-v> and then from a maintainability / code clarity perspective: explicitly passing objects (coins) through a callstack is easier to reason about and has less thread safety issues etc than having each frame do its own map lookup
10:34 < stickies-v> 4. Especially during IBD, transaction validation must be fast. Are there any changes where you have concerns about performance?
10:34 -!- JoaoLeal [~JoaoLeal@2804:1b3:a8c3:22b7:502b:aeff:fe4e:a5da] has joined #bitcoin-core-pr-reviews
10:38 < marcofleon> maybe iterating over the txs in the block twice now? doesn't seem like a big deal though
10:38 < stickies-v> Or if you don't have any concerns: Which measures can you identify this PR has adopted to minimize the performance impact of this refactor?
10:38 < TheCharlatan> there are a few additional vector allocations, where instead of retrieving elements one-by-one, references to elements are filled into a vector and then passed by spans.
10:38 < Davidson> I didn't see anything extraordinary. Maybe use a little bit more memory?
10:39 < Davidson> TheCharlatan: oh you were faster than me :D
10:39 < TheCharlatan> heh :D
10:40 < stickies-v> yeah vector allocations was the main thing I could see too. This PR relies quite heavily on passing references rather than copying, so the overhead there should be quite minimal
10:40 < stickies-v> of course, these references can introduce lifetime risks, so that might be something to consider in your review
10:41 < lightlike> not so important for the question, but I don't agree with the "especially" in the question : In my opinion, validation / block propagation being fast is much more important at the tip than during IBD, which is a one-time thing.
10:42 < Davidson> stickies-v: I assume buildinga spam<T> from a vector<T> is almost free? (Rust bro here :D )
10:42 < stickies-v> lightlike: oh, interesting! yeah, i agree that at the tip performance is also crucial, and it's maybe a bit meaningless to compare which is more important - could have phrased that better, sorry!
10:42 < monlovesmango> I did have  a question about why we pass block_hash as a parameter to ConnectBlock when block.GetHash() is still called when asserting Assume(block.GetHash() == block_hash)
10:44 < stickies-v> Davidson: yes, I'm not enough of a C++ expert to give you the sound answer, but my understanding is that a span allows to iterate over the container with almost no overhead, like a view
10:44 < Davidson> monlovesmango: I believe this is the topic for question number 5, no?
10:45 < stickies-v> it is indeed!
10:45 < Davidson> stickies-v: nice, so it's basically one vec allocation per block with this block's coins. And then we pass refs to that vec
10:45 < marcofleon> is block_hash just sort of used as sanity check in those Spendblock assertions?
10:46 < TheCharlatan> marcofleon: yes :)
10:46 < stickies-v> 5. `SpendBlock()` takes a `CBlock block`, `CBlockIndex pindex` and `uint256 block_hash` parameter, all referencing the block being spent. Why do we need 3 parameters to do that?
10:46 < monlovesmango> Davidson: haha oops
10:47 < marcofleon> the CBlock contains the actual txs that are used to check against and update the utxo set so gotta have that
10:47 < Davidson> So, mostly sanity check...? I've seen that the pindex arg also gets used to figure out if our ChainState represents the previous block's state, so we need this one
10:48 < stickies-v> monlovesmango: `Assume` statements are only compiled into debug builds, so this check should not incur any overhead on non-debug builds
10:48 < stickies-v> otherwise, indeed it would be a bit silly to pass `block_hash` as a performance optimization. good spot!
10:48 < monlovesmango> I assumed the block_hash parameter was for performance reasons, so that we don't have to re-hash
10:48 < monlovesmango> stickies-v: ok!! that makes a lot more sense :)
10:49 < monlovesmango> also good to know that about `Assume` statements
10:49 < marcofleon> pindex also used for the height to cehck against bip30 stuff
10:50 < marcofleon> and for UpdateCoins
10:51 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-pr-reviews
10:51 < monlovesmango> isn't bip30 stuff now in SpendBlock?
10:52 < stickies-v> monlovesmango: yes, the question is about `SpendBlock`
10:52 < monlovesmango> omg ignore sorry..
10:53 < marcofleon> "bip30 stuff" is my best summarizing of that whole chunk of code/text
10:55 < stickies-v> but why do we need to pass `pindex`? Can't it be retrieved from `block`?
10:56 < stickies-v> (and if it can, should it?)
10:57 < Davidson> You mean the prevblock? I think it's better to get the prevblock straight from pindex to make sure we actually building on tip?
10:57 < stickies-v> We're almost at time, so gonna launch the next/last question already
10:57 < stickies-v> 7. The first commits in this PR refactor `CCoinsViewCache` out of the function signature of a couple of validation functions. Does `CCoinsViewCache` hold the entire UTXO set? Why is that (not) a problem? Does this PR change that behaviour?
10:58 < stringintech> I guess we need another disk access for that which is not good to do? (previous question)
10:58 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
10:59 < stickies-v> Davidson: no, I mean dropping the `pindex` argument from the `SpendBlock` fn signature, and just letting `SpendBlock` get a `CBlockIndex` from `block`
10:59 -!- enochazariah [~enochazar@162.245.239.130] has quit [Quit: Client closed]
11:00 < stickies-v> stringintech: I don't think we need disk access for that, the entire block index (`BlockManager::m_block_index`) is kept in-memory, it is relatively small
11:00 < TheCharlatan> Davidson, that is a good reason, but we could also assert that beforehand. Other than that, looking up the block index with a block's hash does incur bit of a performance penalty.
11:01 < stringintech> stickies-v: oh!! thanks.
11:02 < stickies-v> TheCharlatan: sure, it's a lookup, but it's a map - do you think that's going to be measurable?
11:04 < TheCharlatan> I doubt it would be. I think I implemented it that way more because we already have it available at its call sites.
11:04 < Davidson> stickies-v: Oh, I didn't know you could do that :')
11:04 < stickies-v> anyway, we're past end time for today, so I'm going to wrap it up here, but as always feel free to share thoughts or follow-up questions - i'll be around for a while longer!
11:05 < stickies-v> thanks for joining the discussion today everyone, and thanks TheCharlatan for authoring the PR!
11:05 < marcofleon> yeah wait how are we getting a CBlockindex from a CBlock?
11:05 < stickies-v> #endmeeting
11:05 < corebot> stickies-v: Meeting ended at 2025-05-14T18:05+0000
11:05 < corebot> stickies-v: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-05-14_17_00.log.json
11:05 < corebot> stickies-v: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-05-14_17_00.log.html
11:05 < corebot> stickies-v: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-05-14_17_00.html
11:05 < marcofleon> just by getting the hash and then looking it up?
11:05 < TheCharlatan> yes 
11:05 < stickies-v> yeah, `BlockManager::m_block_index` is an unordered_map keyed by block hash
11:05 < TheCharlatan> thanks for hosting stickies-v!
11:06 < Davidson> thanks everyone!
11:06 < marcofleon> got it, thanks
11:06 -!- JoaoLeal [~JoaoLeal@2804:1b3:a8c3:22b7:502b:aeff:fe4e:a5da] has quit [Quit: Client closed]
11:06 < marcofleon> thanks stickies and Charlatan!
11:06 < stringintech> Thank you everyone
11:07 < monlovesmango> thanks for hosting stickies-v and TheCharlatan !!
11:07 < marcofleon> this question: CCoinsViewCache has two methods AccessCoin() and GetCoin() that both return a Coin-like type. What is the difference between both methods, and when should which be used?
11:07 < marcofleon> I'd like to know when they should be used?
11:08 < marcofleon> I can see the differences in return value
11:08 < marcofleon> and what happens if the coin isn't found or not spent
11:09 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
11:10 < stickies-v> yeah there are 2 main differences between those 2 functions:
11:11 < marcofleon> I guess if you're not gonna modify the coin or store it, use Access?
11:11 < stickies-v> `GetCoin` ensures it only returns a `Coin` if it's not spent, whereas `AccessCoin` does not do that
11:11 < stickies-v> second: `GetCoin` returns a copy, whereas `AccessCoin` returns a reference to the `Coin` in `cacheCoins`
11:12 < stickies-v> so `AccessCoin` is naturally going to be more performant, but at the cost of introducing lifetime risk, you can end up with a dangling reference if you're not careful
11:13 < stickies-v> neither is going to allow you to modify the coin, `AccessCoin` returns a `const` reference
11:13 < TheCharlatan> yes, their lifetime is only valid for as long as the cache is not mutated in between, so you should not use it if you plan on doing any other calls to the coins in between.
11:14 < monlovesmango> marcofleon: thanks for asking that I was also interested in that answer
11:15 < marcofleon> perfect, yeah I see it now. thanks for going through that
11:15 < marcofleon> monlovesmango: no problem :) it was a good question, had to know
11:15 < stickies-v> TheCharlatan: I think for unordered_map the references should remain valid as long as not that specific member is erased, though
11:16 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
11:16 < stickies-v> "References and pointers to either key or data stored in the container are only invalidated by erasing that element, even when the corresponding iterator is invalidated." from https://en.cppreference.com/w/cpp/container/unordered_map
11:18 < TheCharlatan> Mmh, right. I guess we could be erasing though when we spend, right?
11:18 < stickies-v> yeah, i think so
11:20 < stickies-v> and i actually had a question on the `IsSpent` check in `GetCoin` - I think in normal operation that should always be false except for when we haven't flushed yet, right?
11:21 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
11:22 < TheCharlatan> mmh, good question, I'll have to check again
11:24 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
11:29 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
11:30 -!- pablomartin_ [~pablomart@217.130.254.81] has quit [Ping timeout: 244 seconds]
11:34 -!- stringintech [~stringint@2602:fa59:3:451::1] has quit [Ping timeout: 240 seconds]
11:52 < marcofleon> TheCharlatan: little nit,  but the name ConnectBlock doesn't match what it's doing in the PR. I think it just does validation now (minus utxo set check)
11:52 < marcofleon> especially because setbestblock got moved as well
11:53 < marcofleon> maybe i'll come up with a briliant new function name tomorrow. I'll keep you posted
11:59 < stickies-v> it doesn't just do validation though, it also updates the block index (bumping validity)
12:06 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
12:17 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
12:18 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 245 seconds]
12:18 -!- PaperSword1 is now known as PaperSword
12:21 -!- PaperSword1 [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
12:22 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 248 seconds]
12:22 -!- PaperSword1 is now known as PaperSword
12:25 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
12:26 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
12:27 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 248 seconds]
12:27 -!- PaperSword1 is now known as PaperSword
12:28 -!- monlovesmango [~monlovesm@146.70.72.141] has quit [Ping timeout: 252 seconds]
12:40 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
13:08 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
13:12 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 245 seconds]
13:12 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:59 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
14:04 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 245 seconds]
14:34 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
15:19 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
15:47 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 245 seconds]
15:50 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
16:01 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
16:03 -!- monlovesmango [~monlovesm@146.70.72.141] has joined #bitcoin-core-pr-reviews
16:06 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 252 seconds]
16:06 -!- monlovesmango [~monlovesm@146.70.72.141] has quit [Client Quit]
17:18 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
17:24 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Remote host closed the connection]
18:17 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
18:19 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 252 seconds]
18:20 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
18:21 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 252 seconds]
18:31 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
18:51 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
20:23 -!- __gotcha [~Thunderbi@79.132.236.44] has quit [Read error: Connection reset by peer]
20:24 -!- __gotcha [~Thunderbi@79.132.236.44] has joined #bitcoin-core-pr-reviews
21:04 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
21:24 -!- greypw1495085720 [~greypw@user/greypw] has quit [Quit: Ping timeout (120 seconds)]
22:08 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
22:08 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
22:13 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
--- Log closed Thu May 15 00:00:44 2025