--- Log opened Wed May 11 00:00:20 2022
00:05 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
00:11 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:653f:cf3c:8f50:7410] has joined #bitcoin-core-pr-reviews
00:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5da5:1c4:f31b:7d74] has quit [Ping timeout: 240 seconds]
00:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5da5:1c4:f31b:7d74] has joined #bitcoin-core-pr-reviews
01:13 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:653f:cf3c:8f50:7410] has quit [Ping timeout: 240 seconds]
01:32 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:653f:cf3c:8f50:7410] has joined #bitcoin-core-pr-reviews
01:39 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
02:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5da5:1c4:f31b:7d74] has quit [Ping timeout: 248 seconds]
02:15 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
02:39 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:653f:cf3c:8f50:7410] has quit [Ping timeout: 240 seconds]
03:10 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews
03:15 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has quit [Ping timeout: 240 seconds]
03:16 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
03:26 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:653f:cf3c:8f50:7410] has joined #bitcoin-core-pr-reviews
03:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5da5:1c4:f31b:7d74] has joined #bitcoin-core-pr-reviews
03:41 -!- Kaizen_K_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has joined #bitcoin-core-pr-reviews
03:41 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:653f:cf3c:8f50:7410] has quit [Ping timeout: 240 seconds]
03:55 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
04:13 -!- Asku [~Asku@lfbn-idf1-1-920-80.w86-238.abo.wanadoo.fr] has joined #bitcoin-core-pr-reviews
04:31 -!- Kaizen_K_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has quit [Ping timeout: 260 seconds]
04:41 -!- Asku [~Asku@lfbn-idf1-1-920-80.w86-238.abo.wanadoo.fr] has quit [Quit: Connection closed]
05:01 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has joined #bitcoin-core-pr-reviews
06:21 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has quit [Ping timeout: 240 seconds]
06:30 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews
06:55 -!- furszy [~furszy@186.141.200.138] has joined #bitcoin-core-pr-reviews
07:08 -!- furszy [~furszy@186.141.200.138] has quit [Remote host closed the connection]
07:10 -!- furszy [~furszy@186.141.200.138] has joined #bitcoin-core-pr-reviews
07:14 < michaelfolkson> The intersection of AssumeUTXO (general codebase improvements excluding additions that are only relevant if user uses AssumeUTXO), multiprocess (general codebase improvements excluding additions that are only relevant if user uses multiprocess) and libbitcoinkernel is a killer
07:17 < michaelfolkson> Starting to appreciate why AssumeUTXO and multiprocess have taken so long now
07:25 < michaelfolkson> Though AssumeUTXO, multiprocess are sufficiently advanced now that they've exhausted the general codebase improvements (I think) and are now at stage where they are just doing additions that are relevant if user uses them
07:26 -!- Trigger67 [~Trigger67@2a01:e0a:eb:3720:17d0:1f7:37c5:421d] has joined #bitcoin-core-pr-reviews
07:34 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 252 seconds]
07:35 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has quit [Ping timeout: 260 seconds]
07:44 -!- furszy [~furszy@186.141.200.138] has quit [Remote host closed the connection]
07:53 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
07:59 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
08:01 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has joined #bitcoin-core-pr-reviews
08:03 -!- furszy [~furszy@2800:810:5ea:88bb:7d7c:6e2e:4e7b:68b] has joined #bitcoin-core-pr-reviews
08:09 -!- furszy [~furszy@2800:810:5ea:88bb:7d7c:6e2e:4e7b:68b] has quit []
08:14 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
08:19 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
08:38 -!- Trigger67 [~Trigger67@2a01:e0a:eb:3720:17d0:1f7:37c5:421d] has quit [Ping timeout: 252 seconds]
08:43 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
09:00 < michaelfolkson> This is handy for big picture stuff on libraries around libbitcoinkernel https://github.com/ryanofsky/bitcoin/blob/pr/libs/doc/design/libraries.md
09:08 < michaelfolkson> Though I think I'm still struggling on what is WIP multiprocess stuff and how libbbitcoinkernel is going to gel with that
09:14 < michaelfolkson> If libbitcoinkernel embeds into the multiprocess stuff it goes in the direction of the user deciding Yes/No on each of AssumeUTXO, multiprocess and libbitcoinkernel
09:23 < _aj_> aiui; kernel is just architectural, and will change how bitcoind is linked, not something users will choose. multiprocess is a more substantial change, so presumably will stay a compile-time option until there's a lot of confidence that it works great everywhere; assumeutxo is always a runtime choice
09:24 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 246 seconds]
09:32 < michaelfolkson> I was thinking it might evolve so to begin with only users that need it would use it (alternative implementations seeking a consensus engine) and those using Bitcoin Core in its entirety might not use it
09:33 < michaelfolkson> I guess it depends how much complexity is involved in "just architectural"
09:35 < _aj_> possible; i expect it'll be used internally before anyone picks it up and builds on it externally though
09:35 < sipa> libbitcoinkernel isn't (initially) intended to be usable by alternative implementations, i think
09:35 < michaelfolkson> Whether it evolves in parallel with "legacy Core" or "legacy Core" is entirely (slowly) replaced by a Core with libbbitcoinkernel at center
09:36 < sipa> libbitcoinkernel is just separating things within core, it's not intended to replace anythng
09:37 < michaelfolkson> But it seems a very complex separation right? So could be experimental in places
09:37 < sipa> that would defeat the purpose
09:39 < _aj_> the Makefile allocates various .cpp files to different libraries; libbitcoin_util, _node, etc. atm we've added _kernel and validation.cpp goes into both _kernel and _node. the idea is eventually it will just be in _kernel. the idea isn't to meaningfully change the way validation.cpp works, beyond having a clean separation between _kernel and _node that doesn't exist now (because everything's 
09:39 < _aj_> in _node)
09:39 < _aj_> (aiui; as i understand it)
09:40 < _aj_> the separation shouldn't really be complex, just detailed
09:41 < michaelfolkson> sipa: I don't think it would defeat the purpose entirely though it depends on specifically which purpose(s) we are talking about. And the long term goal could be to ditch the experimental, but have it in parallel in the short term
09:41 < michaelfolkson> Maybe I've got the wrong end of stick on how hard this is going to be (_aj_ comments)
09:46 -!- david-bakin [~david-bak@c-174-61-163-5.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews
09:46 < michaelfolkson> Starting with Coinstats (today's PR) makes sense to me anyway. That seems relatively simple to separate out and definitely shouldn't overlap with the "consensus engine"
09:49 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:50 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:51 < dongcarl> Yeah I think the _eventual_ goal (aka Step 2) is to make it consumable externally, but Step 1 is just about the separation between the consensus engine and the rest of the codebase
09:53 < larryruane> if i may ask a goofy question, the PR starts with "[kernel 2a/n]" ... how is this string determined? what strings are allowed inside the square brackets?
09:53 < dongcarl> s/Step/Stage/
09:53 < dongcarl> larryruane: It was determined by my own whim lol
09:54 < dongcarl> My current numbering scheme (which has been asked about a few times), is just to bump the major number if it depends on things in the previous major number. E.g. kernel 3 would depend on kernel 2a/2b/2c, etc.
09:55 < dongcarl> (very likely that inconsistencies will arise in this scheme in the future)
09:55 < larryruane> cool I was going to ask you what the "a" meant in "2a" ... so "2a", "2b" (etc) could be merged in either order? But all "2"s before any "3"s?
09:56 < dongcarl> Yup!
09:56 < larryruane> thanks! very helpful
09:56 < lightlike> oh, i thought it was based on https://github.com/bitcoin/bitcoin/issues/24303 and all decouplings of non-consensus code would start with 2
09:57 < larryruane> could i ask very quickly too, i've heard that a PR's description (first comment) should be somewhat concise and limited, because it ends up in the git log history, and put details in a second comment .. is that true?
09:59 < _aj_> larryruane: i like that approach; first comment should describe the PR's aim in a "timeless" way; if you want to add advice to reviewers, put it in a second comment. but just my opinion
09:59 < larryruane> thanks
10:00 < dongcarl> #startmeeting
10:00 < josibake> hi
10:00 < dongcarl> hello all
10:00 < larryruane> hi!
10:00 < lightlike> hi
10:01 < glozow> hi!
10:01 < dongcarl> we'll wait a few secs for people to show up, please say "hi" if you're here and at your keyboard!
10:01 -!- otech [~otech@80.251.179.171] has joined #bitcoin-core-pr-reviews
10:01 -!- oliver92 [~oliver@187.85.169.199] has joined #bitcoin-core-pr-reviews
10:02 < dongcarl> We'll be discussing [kernel 2a/n] Split hashing/index `GetUTXOStats` codepaths, decouple from `coinstatsindex` today, link: https://bitcoincore.reviews/24410
10:02 < sipa> "hi"
10:02 < michaelfolkson> hi
10:02 < otech> 👋
10:02 < oliver92> sup
10:02 -!- sanya [~sanya@178-222-17-95.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
10:03 -!- Azor [~Azor@200.109.50.144] has joined #bitcoin-core-pr-reviews
10:03 < dongcarl> Just so people know the ground rules: If you have a question, you don't have to ask to ask a question, just go ahead and ask!
10:03 < larryruane> (sipa doesn't really mean it)
10:03 < dongcarl> larryruane: He's being literal! :-)
10:03 < larryruane> :)
10:04 < dongcarl> Okay! Let's get started.
10:04 < dongcarl> Did everyone get a chance to review the PR? How about a quick y/n from everyone
10:04 -!- neha [~neha@41.213.196.104.bc.googleusercontent.com] has joined #bitcoin-core-pr-reviews
10:04 < josibake> y
10:04 < michaelfolkson> y
10:04 < oliver92> n
10:04 < larryruane> n
10:04 < lightlike> y
10:05 < otech> n
10:05 < dongcarl> Okay, let's get into the questions...
10:05 < dongcarl> For those of you who reviewed... Concept ACK, approach ACK, tested ACK, or NACK?
10:06 < josibake> Concept ACK
10:06 < effexzi> N
10:06 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:07 < michaelfolkson> Approach ACK. A good choice for 2a :)
10:07 < lightlike> approach ACK
10:07 < dongcarl> Cool. Next one!
10:07 < dongcarl> On a conceptual level, which modules in Bitcoin Core likely belong in libbitcoinkernel and which ones don’t?
10:08 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:08 < oliver92> I'd say anything consensus-related && stateless
10:08 < josibake> what exactly does module mean in this context? is there a specific meaning or just more generally "a logical collection of code"
10:08 < larryruane> at a very high level, any code that, if implemented differently, could cause consensus failures (chain split) should be in libbitcoinkernel (else not)
10:09 < larryruane> (differently on different nodes on the network)
10:09 < dongcarl> josibake: Logical collection of code!
10:09 -!- antonleviathan [~antonlevi@cpe08a7c0b41e4e-cm08a7c0b41e4c.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews
10:09 < michaelfolkson> Yeah node validation, not P2P, wallet, GUI etc
10:09 -!- randomsats [~randomsat@cpe1033bfa9e0e7-cm1033bfa9e0e5.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews
10:09 < antonleviathan> o/
10:09 < larryruane> RBF policies are an example of what would NOT be included
10:10  * dongcarl waves hello to the newcomers
10:10 < dongcarl> Right, lots of good answers there.
10:10 < michaelfolkson> secp256k1?!
10:10 < larryruane> definitely!
10:10 < michaelfolkson> Surely part of the consensus engine
10:10 < dongcarl> To touch on oliver92's answer, statelessness is not a goal of libbitcoinkernel, but was a goal of libbitcoinconsensus (as I understood it)
10:11 < dongcarl> As michaelfolkson said, P2P, Wallet, GUI are all things that definitely do not belong in libbitcoinkernel
10:12 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
10:12 < larryruane> if some part of the code is "stateless" (just so i understand), does that mean only has pure functions?
10:12 < dongcarl> larryruane: In my view it'd just not have persistence, there might be local state
10:13 < michaelfolkson> secp256k1 would be a separate library from libbitcoinkernel but still part of the consensus engine
10:13 < dongcarl> michaelfolkson: Right now, we embed secp256k1 inside libbitcoinkernel
10:13 < michaelfolkson> Ohh ok, cool
10:13 < svav> Hi
10:14 < dongcarl> The overall philosophy is "outside-in" and "incremental" meaning that we'll slowly whittle things down, and not aim for a minimal library all at once :-)
10:14 < dongcarl> Let's move on!
10:14 < dongcarl> Where in the Bitcoin Core codebase can you see libbitcoinkernel’s entanglement with index? (There might be multiple places)
10:14 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:14 < dongcarl> (This is as of master)
10:14 < lightlike> will the mempool  be taken out of libbitcoinkernel too?
10:15 -!- oliver92 [~oliver@187.85.169.199] has quit [Quit: Connection closed]
10:15 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
10:15 < dongcarl> lightlike: Good question! I think we can ship libbitcoinkernel with mempool (since mempool <-> validation is quite tightly coupled), and most external users will want to use Core's policy, but perhaps there will be a configure flag later to not link it in.
10:17 -!- sanya [~sanya@178-222-17-95.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
10:18 < josibake> at the risk of giving the obvious answer, we see `libitcoinkernel` entangled with index is when calling `PopulateAndValidateSnapshots`
10:18 < dongcarl> josibake: That is correct :-)
10:18 < josibake> `PopulateAndValidateSnapshots` is only for assumeutxo, correct? 
10:19 < dongcarl> josibake: Yup!
10:19 < fanquake> mempool = boost 🥲
10:20 < dongcarl> fanquake: I feel 🥲 too, but we do one thing at a time in this project!
10:20 < sipa> boost is headers only this day, no?
10:20 < josibake> just curious (and feel free to bunt if this is off topic) but why is assumeutxo in libbitcoinkernel? instead of breaking up `GetUTXOstats` , why not move assumeutxo out of libbitcoinkernel?
10:20 < fanquake> sipa: yea
10:20 < sipa> @fanquake Not a big concern then, as it doesn't cause a libbitcoinkernel dependency.
10:20 < fanquake> multi_index might even be in-tree soon enough anyways
10:21 < dongcarl> josibake: I think moving assumeutxo out of validation will be much more work than separating the two codepaths of GetUTXOStats, and the two codepaths needed separation in any case
10:21 < dongcarl> Okay back to the question
10:21 < fanquake> It's a dependency in the sense that you still need boost. no libs sure
10:21 < dongcarl> Can anyone spot another point where you can see the entaglement between libbitcoinkernel and index/ in the build system code?
10:21 < lightlike> btw, the function is "PopulateAndValidateSnapshot" (without an s) in case anyone else was looking it up
10:22 < dongcarl> (e.g. src/Makefile.am)
10:22 < sipa> @fanquake I meant runtime dependency, but indeed.
10:25 < dongcarl> For the sake of time, I'll answer my own question, the index/ files are listed under libbitcoinkernel_la_SOURCES, and if you remove them, there will be linker errors: https://github.com/bitcoin/bitcoin/blob/9db941d7737406b8593024ba130c3f9c186af4c6/src/Makefile.am#L848-L875
10:26 < dongcarl> Next! Question 4: What is the CCoinsStats struct, and how is it used in GetUTXOStats?
10:26 < josibake> so as of now, the only index one remaining (after this pr) is `index/blockfilterindex.cpp` 
10:27 < dongcarl> josibake: Kinda! That was just leftover from #21726, it's removed in https://github.com/bitcoin/bitcoin/pull/24410/commits/195c96ad88bf97aee3ff5597339659451470864f
10:30 < lightlike> CCoinsStats has various kinds of statistics about the utxos at one block, and GetUTXOStats fills it with the correct info
10:31 < dongcarl> lightlike: Yup! There's a bit more nuance to that though, hint: what you say is true as of after my PR, but not technically true in master.
10:33 < michaelfolkson> dongcarl: Can you elaborate? Looks to me like that that is true in master...
10:33 -!- josedrobles [~jdrobpar@154.red-88-20-17.staticip.rima-tde.net] has joined #bitcoin-core-pr-reviews
10:33 < lightlike> oh yes, right now it's also pre-filled with inputs, such as whether to use an index or not
10:34 < lightlike> and the hash type. so it's both in and out
10:34 < dongcarl> lightlike: That's exactly right, CCoinsStats (as of master) is a struct that’s serving the role of an in-out param in GetUTXOStats, as in it contains certain members that are logical inputs to GetUTXOStats (hash_type, index_requested), and certain members that are logical outputs of GetUTXOStats (hashSerialized, etc.).
10:35 < josibake> ah, i now understand what was meant by in-out param in the PR :) 
10:35 < dongcarl> Note that in this PR, we remove the logical inputs to make CCoinsStats a pure out-param
10:35 < dongcarl> josibake: Oh! Perhaps I should explain the terminology more carefully in the commit messages :-)
10:36 < dongcarl> Okay on to the next one
10:36 < dongcarl> Question 5: Please describe how GetUTXOStats is called in ChainstateManager::PopulateAndValidateSnapshot and what codepath(s) it takes when called in this way.
10:36 < dongcarl> Link for ChainstateManager::PopulateAndValidateSnapshot https://github.com/bitcoin/bitcoin/blob/12455acca2c3adf5c88ae9c1a02a7c192fe0f53b/src/validation.cpp#L4970
10:36 < dongcarl> Note: We're looking at master
10:38 < dongcarl> Not: We don't particularly care about how PopulateAndValidateSnapshot works, just how it calls GetUTXOStats
10:39 < dongcarl> s/Not/Note/
10:40 < lightlike> it uses HASH_SERIALIZED as hash type and the default for index_requested (true) - but the latter doesnt matter with HASH_SERIALIZED.
10:41 < dongcarl> lightlike: Expand on that a bit, why doesn't the latter matter with HASH_SERIALIZED?
10:42 < lightlike> because in GetUTXOStats, we only use the index to lookup the data for hash type MUHASH or NONE. 
10:44 < dongcarl> Yup that's exactly right :-) There's no chance for us to use the coinstatsindex in the way that we call GetUTXOStats from PopulateAndValidateSnapshot, and that's why we can remove it from libbitcoinkernel
10:44 < lightlike> https://github.com/bitcoin/bitcoin/blob/9db941d7737406b8593024ba130c3f9c186af4c6/src/node/coinstats.cpp#L109
10:44 < dongcarl> Exactly!
10:45 < dongcarl> Okay, a similar question, but a little more involved: Please describe how GetUTXOStats is called for the gettxoutsetinfo RPC and what codepath(s) it takes when called in this way.
10:45 < dongcarl> Link for gettxoutsetinfo: https://github.com/bitcoin/bitcoin/blob/194b414697777b5ac9d9918004b851dbd4f8ce17/src/rpc/blockchain.cpp#L811
10:46 < dongcarl> Note: this one will require looking at a little bit of surrounding code in the gettxoutsetinfo RPC function
10:49 < lightlike> not sure if this is what is asked, but on a high level it sets the parameter based on  user input. i.e. the user can specify the hash type and whether to use an index, and the parameters are set accordingly.
10:50 < josibake> yeah, same answer. the user can pass in hash_type, where its one of "hash_serialized_2", "muhash", "none"
10:51 < dongcarl> All correct, I think the thing worth pointing out is that when the user specifies a particular block, they have to use the coinstatsindex
10:51 < josibake> also, oddly, it's called once in the first if block and the boolean is checked, and then it's called again later in the same if block but the boolean isn't checked 
10:51 < josibake> which seems odd 
10:52 < dongcarl> josibake: That's an oversight that we fix in my PR actually haha
10:52 < josibake> dongcarl: nice! 
10:53 < dongcarl> Okay last question!
10:53 < dongcarl> After this PR is merged, what would happen if a contributor re-introduced a dependency from validation to the Coinstats Index?
10:54 < dongcarl> (in the C++ code)
10:54 < larryruane> linker error?
10:55 < dongcarl> larryruane: That's correct! Can you tell me why?
10:57 < larryruane> I thought I understood but now I'm not sure :)
10:58 < lightlike> I'd say CI error (isn't bitcoin-chainstate currently not built by default, but only when some extra flag is specified?)
10:58 < dongcarl> lightlike: Ah! We are assuming that we build bitcoin-chainstate :-)
10:59 < lightlike> maybe we all should, I haven't updated my script yet :-)
10:59 < dongcarl> Here's my answer: Because index/coinstatsindex.cpp is no longer listed in libbitcoinkernel_la_SOURCES, it won't be linked into libbitcoinkernel, therefore anything that links against libbitcoinkernel (e.g. bitcoin-chainstate) will fail to link since the coinstatsindex symbols aren't defined.
10:59 < dongcarl> lightlike: :-)
11:00 < dongcarl> Okay! Thanks everyone for attending!
11:00 < josibake> thanks for hosting! i learned a lot 
11:00 < otech> thanks!
11:00 < lightlike> thanks dongcarl!
11:00 < josibake> also kudos on the PR, the commits are broken up very nicely
11:00 < larryruane> thanks carl!
11:00 < dongcarl> Was great fun talking with y'all, and feel free to stick around for questions/discussions!
11:00 < svav> Thanks dongcarl and all
11:00 < dongcarl> #endmeeting
11:00 < dongcarl> Poor s t i c k
11:02 < michaelfolkson> Thanks dongcarl!
11:05 -!- otech [~otech@80.251.179.171] has quit [Quit: Connection closed]
11:05 < effexzi> Thanks every1 
11:05 < michaelfolkson> If anyone is interested in a high level overview of the project Carl did a great short video https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/
11:05 < michaelfolkson> https://www.youtube.com/watch?v=MdxIkH6GCBs
11:05 < dongcarl> michaelfolkson: Oh! Thanks for writing up the transcript!
11:07 < dongcarl> Linked to it from my video
11:08 -!- Azor [~Azor@200.109.50.144] has quit [Quit: Connection closed]
11:08 < michaelfolkson> No worries, was a good one. I'm struggling to understand how it is going to evolve (but maybe you are too or maybe you've got the roadmap very clear in your head!)
11:09 < michaelfolkson> Or at least how you see it going before others pitch in thoughts
11:09 < dongcarl> michaelfolkson: I've got an okay-picture in my head, mostly following "The Game Plan" in https://github.com/bitcoin/bitcoin/issues/24303#issue-1129004032
11:11 < michaelfolkson> You'll be passing the baton on for library API design though :)
11:12 < dongcarl> Yup! But I think even Stage 1 is quite impactful for the repo.
11:12 < dongcarl> Library API design is a different beast entirely haha
11:13 < michaelfolkson> Yup Stage 1 definitely impactful
11:44 -!- antonleviathan [~antonlevi@cpe08a7c0b41e4e-cm08a7c0b41e4c.cpe.net.cable.rogers.com] has quit [Ping timeout: 252 seconds]
11:59 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
12:23 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
12:25 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 252 seconds]
12:26 -!- lukedashjr is now known as luke-jr
12:27 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has quit [Ping timeout: 260 seconds]
12:29 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:31 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews
12:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5da5:1c4:f31b:7d74] has quit [Remote host closed the connection]
12:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has quit [Remote host closed the connection]
12:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has joined #bitcoin-core-pr-reviews
12:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5da5:1c4:f31b:7d74] has joined #bitcoin-core-pr-reviews
12:57 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has quit [Remote host closed the connection]
12:58 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has joined #bitcoin-core-pr-reviews
13:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5da5:1c4:f31b:7d74] has quit [Ping timeout: 260 seconds]
13:03 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 240 seconds]
13:11 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
13:14 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has quit [Ping timeout: 252 seconds]
13:17 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has joined #bitcoin-core-pr-reviews
13:18 -!- hashfunc802 [~user@2601:5c0:c280:7090:7c25:cf68:625f:614f] has joined #bitcoin-core-pr-reviews
13:21 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has quit [Ping timeout: 240 seconds]
13:37 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has joined #bitcoin-core-pr-reviews
13:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:7f:79e6:f06c:b27e] has quit [Ping timeout: 240 seconds]
13:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews
13:59 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has quit [Ping timeout: 240 seconds]
13:59 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@ip72-194-104-106.oc.oc.cox.net] has joined #bitcoin-core-pr-reviews
14:12 -!- josedrobles [~jdrobpar@154.red-88-20-17.staticip.rima-tde.net] has quit [Quit: Konversation terminated!]
14:50 -!- hashfunc802 [~user@2601:5c0:c280:7090:7c25:cf68:625f:614f] has quit [Ping timeout: 260 seconds]
15:10 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:38 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Remote host closed the connection]
17:07 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
17:13 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
17:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f9c0:53d9:d76e:e362] has joined #bitcoin-core-pr-reviews
17:38 -!- stijnbtc[m]1 [~stijnbtcm@2001:470:69fc:105::2:cc] has quit [Ping timeout: 240 seconds]
17:39 -!- cryptoquick [~cryptoqui@8.46.89.33] has quit [Quit: Ping timeout (120 seconds)]
17:39 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 240 seconds]
17:39 -!- rodentrabies[m] [~rodentrab@2001:470:69fc:105::1:2404] has quit [Ping timeout: 260 seconds]
17:39 -!- dunxen [~dunxen@2001:470:69fc:105::1:fec1] has quit [Ping timeout: 260 seconds]
17:39 -!- Murch [~murch@user/murch] has quit [Ping timeout: 252 seconds]
17:39 -!- sr_gi[m] [~srgimatri@2001:470:69fc:105::1:c14c] has quit [Ping timeout: 256 seconds]
17:39 -!- willcl_ark [~willcl-ar@user/willcl-ark/x-8282106] has quit [Ping timeout: 256 seconds]
17:39 -!- cryptoquick [~cryptoqui@8.46.89.33] has joined #bitcoin-core-pr-reviews
17:39 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has quit [Ping timeout: 248 seconds]
17:39 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has quit [Ping timeout: 260 seconds]
17:39 -!- stijnbtc[m] [~stijnbtcm@2001:470:69fc:105::1:fec3] has quit [Ping timeout: 260 seconds]
17:39 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Ping timeout: 248 seconds]
17:39 -!- jomat [~jomat@2001:470:69fc:105::21] has quit [Ping timeout: 256 seconds]
17:42 -!- randomsats [~randomsat@cpe1033bfa9e0e7-cm1033bfa9e0e5.cpe.net.cable.rogers.com] has quit [Quit: Connection closed]
18:05 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
18:08 -!- rodentrabies[m] [~rodentrab@2001:470:69fc:105::1:2404] has joined #bitcoin-core-pr-reviews
18:09 -!- dunxen [~dunxen@2001:470:69fc:105::1:fec1] has joined #bitcoin-core-pr-reviews
18:15 -!- sipa [~sipa@user/sipa] has joined #bitcoin-core-pr-reviews
18:16 -!- realtbast[m] [~realtbast@2001:470:69fc:105::1:69a9] has joined #bitcoin-core-pr-reviews
18:19 -!- david-bakin [~david-bak@c-174-61-163-5.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
18:21 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
18:27 -!- stijnbtc[m]1 [~stijnbtcm@2001:470:69fc:105::2:cc] has joined #bitcoin-core-pr-reviews
18:27 -!- sr_gi[m] [~srgimatri@2001:470:69fc:105::1:c14c] has joined #bitcoin-core-pr-reviews
18:29 -!- willcl_ark [~willcl-ar@user/willcl-ark/x-8282106] has joined #bitcoin-core-pr-reviews
18:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f9c0:53d9:d76e:e362] has quit [Ping timeout: 248 seconds]
18:33 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #bitcoin-core-pr-reviews
18:34 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
18:43 -!- Murch [~murch@user/murch] has joined #bitcoin-core-pr-reviews
18:47 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 250 seconds]
18:48 -!- dunxen [~dunxen@2001:470:69fc:105::1:fec1] has quit [Ping timeout: 250 seconds]
18:48 -!- stijnbtc[m]1 [~stijnbtcm@2001:470:69fc:105::2:cc] has quit [Ping timeout: 240 seconds]
18:49 -!- stijnbtc[m] [~stijnbtcm@2001:470:69fc:105::1:fec3] has joined #bitcoin-core-pr-reviews
18:49 -!- siv2r[m] [~siv2rmatr@2001:470:69fc:105::fed3] has joined #bitcoin-core-pr-reviews
18:54 -!- jomat [~jomat@2001:470:69fc:105::21] has joined #bitcoin-core-pr-reviews
19:01 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
19:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f9c0:53d9:d76e:e362] has joined #bitcoin-core-pr-reviews
19:03 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
19:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f9c0:53d9:d76e:e362] has quit [Ping timeout: 260 seconds]
19:10 -!- dunxen [~dunxen@2001:470:69fc:105::1:fec1] has joined #bitcoin-core-pr-reviews
19:10 -!- stijnbtc[m]1 [~stijnbtcm@2001:470:69fc:105::2:cc] has joined #bitcoin-core-pr-reviews
19:11 -!- sipa [~sipa@user/sipa] has joined #bitcoin-core-pr-reviews
19:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f9c0:53d9:d76e:e362] has joined #bitcoin-core-pr-reviews
19:53 -!- test [~test@104.28.77.175] has joined #bitcoin-core-pr-reviews
19:54 -!- test [~test@104.28.77.175] has quit [Client Quit]
20:14 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 276 seconds]
20:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f9c0:53d9:d76e:e362] has quit [Ping timeout: 260 seconds]
20:26 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
20:50 -!- TheRec [~toto@user/therec] has quit [Ping timeout: 276 seconds]
20:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f9c0:53d9:d76e:e362] has joined #bitcoin-core-pr-reviews
21:05 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
22:15 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
22:29 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
22:56 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
23:33 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
23:33 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
23:45 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
--- Log closed Thu May 12 00:00:21 2022