19:01:06 <laanwj> #startmeeting 
19:01:07 <core-meetingbot`> Meeting started Thu Feb 10 19:01:06 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:01:07 <core-meetingbot`> Available commands: action commands idea info link nick
19:01:18 <MarcoFalke> It's not always the answer, though. It could also be "because no one has reviewed X"
19:01:25 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball
19:01:27 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:30 <achow101> hi
19:01:30 <MarcoFalke> hi
19:01:32 <b10c> hi
19:01:33 <larryruane> hi
19:01:35 <cfields> hi
19:01:42 <dongcarl> hi
19:01:42 <laanwj> sure, if there is an implementation the question could be 'why is it not being merged'
19:01:46 <fjahr> hi
19:01:52 <hebasto> hi
19:01:57 <fanquake> hi
19:02:04 <michaelfolkson> hi
19:02:39 <laanwj> two proposed meeting topics then: libbitcoinkernel initial discussion + Q&MaybeA (dongcarl), Discontinue release notes wiki (MarcoFalke)
19:02:43 <laanwj> any last minute ones?
19:03:10 <Kaizen_Kintsugi_> hi
19:03:49 <laanwj> the feature freeze is in 5 days, so i think instead of high priority for review, it might be more useful to review what has the 0.23 milestone and is a feature
19:04:00 <laanwj> https://github.com/bitcoin/bitcoin/milestone/52
19:04:08 <jonatack> hi
19:04:37 <laanwj> e.g. #24115
19:04:40 <gribble> https://github.com/bitcoin/bitcoin/issues/24115 | ARMv8 SHA2 Intrinsics by prusnak · Pull Request #24115 · bitcoin/bitcoin · GitHub
19:05:05 <laanwj> and #24187
19:05:07 <gribble> https://github.com/bitcoin/bitcoin/issues/24187 | Followups for getdeploymentinfo by ajtowns · Pull Request #24187 · bitcoin/bitcoin · GitHub
19:05:38 <laanwj> i'm not sure about #19602 last minute to be honest
19:05:42 <gribble> https://github.com/bitcoin/bitcoin/issues/19602 | wallet: Migrate legacy wallets to descriptor wallets by achow101 · Pull Request #19602 · bitcoin/bitcoin · GitHub
19:05:48 <MarcoFalke> Yeah, could remove that
19:05:57 <laanwj> might be better to (if it is ready) merge it early in 24.0 merge window
19:05:59 <MarcoFalke> Maybe was a bit too optimistic back when I tagged it
19:06:02 <achow101> It would be a bit last minute to merge that
19:06:09 <laanwj> yes, bumped it
19:06:23 <achow101> unfortunately it has not gotten much review
19:06:29 <MarcoFalke> Don't think it had any in-depth review at all yet?
19:07:03 <laanwj> it's one that needs a lot of review and testing, with different wallets
19:08:19 <laanwj> at least it adds a RPC to do the migration manually; it doesn't do it automatically, now that would be risky
19:08:50 <laanwj> #15774 doesn't seem realistic for 23.0?
19:08:52 <gribble> https://github.com/bitcoin/bitcoin/issues/15774 | macOS App Notarization · Issue #15774 · bitcoin/bitcoin · GitHub
19:09:31 <laanwj> don't actually know what it's involved, would it need a PR?
19:09:35 <MarcoFalke> fanquake promised somewhere that it will be fixed for 23.0 ;)
19:09:39 <laanwj> ok
19:09:44 <laanwj> will ask him personally then
19:09:51 <MarcoFalke> fanquake: ^
19:10:00 <MarcoFalke> He might be present
19:10:03 <fanquake> it will be fixed
19:10:28 <laanwj> i don't think we have any other features tagged 23.0?
19:10:34 <laanwj> fanquake: awesome!
19:11:57 <laanwj> is there anything not tagged that might be realistic to make the feature freeze?
19:12:25 <jonatack> not a feature so apologies if irrelevant, but #20196 seems to be a bugfix that has been around since Oct 2020, has seen quite a bit of review, and had acks by sipa and myself
19:12:28 <gribble> https://github.com/bitcoin/bitcoin/issues/20196 | net: fix GetListenPort() to derive the proper port by vasild · Pull Request #20196 · bitcoin/bitcoin · GitHub
19:12:44 <jonatack> (needs rebase though)
19:13:06 <laanwj> ok tagged
19:14:15 <hebasto> in gui repo only a bugfix is tagged for 23.0
19:14:27 <laanwj> hebasto: thanks for checking
19:15:54 <laanwj> ok, that concludes this topic i guess, feel free to ping me outside the meeting if any feature is ready for merge before the feature freeze
19:16:01 <laanwj> #topic libbitcoinkernel initial discussion + Q&MaybeA (dongcarl)
19:16:02 <core-meetingbot`> topic: libbitcoinkernel initial discussion + Q&MaybeA (dongcarl)
19:16:10 <dongcarl> Hi all, I’ve been working libbitcoinkernel: on a plan to extract our consensus engine. I’ve written enough code to see that it can work, and I’d like to share it with you all!
19:16:18 <dongcarl> Here is the umbrella issue: https://github.com/bitcoin/bitcoin/issues/24303
19:16:19 <dongcarl> Here is the first PR: https://github.com/bitcoin/bitcoin/pull/24304
19:16:22 <laanwj> woohoo!!!
19:16:24 <provoostenator> Cool!
19:16:28 <dongcarl> I’ve written up quite a lot between the issue and the PR description and the commit messages, and I’m happy to answer questions and discuss! (Sorry jeremyrubin I just saw your response from yesterday, will reply)
19:16:33 <jonatack> nice
19:16:49 <dongcarl> :D
19:17:12 <laanwj> glad to hear you're making progress there
19:17:23 <laanwj> #24303 #24304
19:17:24 <gribble> https://github.com/bitcoin/bitcoin/issues/24303 | The `libbitcoinkernel` Project · Issue #24303 · bitcoin/bitcoin · GitHub
19:17:24 <gribble> https://github.com/bitcoin/bitcoin/issues/24304 | [kernel 0/n] Introduce `bitcoin-chainstate` and `libbitcoinkernel` by dongcarl · Pull Request #24304 · bitcoin/bitcoin · GitHub
19:18:00 <laanwj> and that your conclusion was that it can actually work, not unimportant
19:18:08 <dongcarl> Yeah I think I had to do some exploring at first, but I think the MVP (stage 1) turned out to be less work than I thought!
19:19:04 <laanwj> great! we've come a long way with modularization and untangling things that should help
19:19:31 <dongcarl> I think there will be some idiosyncrasies in how the API/library works, but I think it is a big win to get the decoupling work done, and we can make the library/API ergonomic at any time
19:20:03 <laanwj> absolutely
19:20:14 <dongcarl> One key insight here is that after we decouple, any re-coupling results in a linker/compiler failure
19:20:27 <dongcarl> So it's good to get the decoupling through first, since that's a big win
19:20:47 <michaelfolkson> Why was a new approach required from libbitcoinconsensus? Or is this building on top of the work done in libbitcoinconsensus?
19:21:11 <michaelfolkson> I know you say "it is a stateful library that can spawn threads, do caching, do I/O, and many other things which one may not normally expect from a library." Sounds like libbitcoinconsensus couldn't do that
19:21:12 <laanwj> basically because it's stateful
19:21:19 <laanwj> yes
19:21:44 <dongcarl> michaelfolkson: libbitcoinconsensus also only does scipt verification last time I checked
19:21:58 <dongcarl> No block or UTXO management logic
19:22:21 <jonatack> Uploaded file: https://uploads.kiwiirc.com/files/f9a8a6e88e0ed1c63f927346339b640f/pasted.txt
19:22:22 <cfields> +100 for libbitcoinconsensus. I've been hacking on carl's branches a bit, and some single-use tools quickly emerged. It's VERY cool.
19:22:46 <jonatack> michaelfolkson: if I may, just posted a file with notes I took on this
19:22:49 <cfields> er, libbitcoinkernel. sorry :)
19:23:07 <michaelfolkson> So libbitcoinconsensus was like a first attempt and this is now a second attempt learning lessons from libbitcoinconsensus?
19:23:14 <michaelfolkson> jonatack: Thanks!
19:23:22 <dongcarl> Hehe yeah cfields built a cool bitcoin-reindex tool with it!
19:24:05 <cfields> michaelfolkson: bitcoinconsensus was very limited and not all that useful with what it can do realistically. libbitcoinkernel is more like a minimized version of a core node impl with no useful interfaces baked in.
19:24:12 <jonatack> michaelfolkson: (those were comments on IRC here by laanwj)
19:24:39 <michaelfolkson> Ok cool
19:24:45 <dongcarl> :-)
19:25:07 <dongcarl> BTW, I'm actively looking for people to take on Stage 2 as mentioned here: https://github.com/bitcoin/bitcoin/issues/24303
19:25:37 <dongcarl> If anyone thinks they're even remotely suited to the task, lmk!
19:26:22 <provoostenator> dongcarl: how does this jibe with ryanofsky's multiprocess stuff?
19:26:36 <laanwj> maybe someone can do a rust binding :-)
19:26:40 <provoostenator> I guess this just takes a chunck out of what was already contained in the node?
19:27:25 <laanwj> multiprocess is about running multiple processes, this is about splitting the code, it's related but not the same
19:27:57 <provoostenator> Right, but if both involve splitting code
19:28:23 <provoostenator> E.g. we got rid of all these globals and now have interfaces.
19:28:26 <dongcarl> Right, I think in practice libbitcoinkernel will probably be a subset of bitcoin-node (is that the right binary?), as in bitcoin-node can link against libbitcoinkernel (not proposing that we do this yet)
19:28:29 <laanwj> it could help multiprocess
19:28:35 <larryruane> would libbitcoinkernel be a separate repo?
19:28:45 <laanwj> larryruane: n-no plans like that for the forseaable future
19:28:47 <MarcoFalke> I'd say it shouldn't affect multiprocess, as libbitcoinkernel will be wrapped in the "Node" (from the view of multiprocess interfaces)
19:29:31 <dongcarl> Yeah right now I have a src/kernel/ directory where I keep libbitcoinkernel specific stuff. No plans yet of repo separation
19:30:04 <dongcarl> Great questions btw :-)
19:31:07 <MarcoFalke> so validation.cpp would eventually move to src/kernel/validation.cpp ?
19:31:26 <laanwj> the actual validation parts, i suppose
19:32:05 <dongcarl> Exactly right. The parts of src/validation.cpp that we absolutely require for the consensus engine would be moved to src/kernel/validation.cpp
19:32:17 <dongcarl> The rest can stay in src/validation.cpp
19:32:45 <lightlike> isn't it more the other way round, that the index rework of #24230 helps for this project too? If the indexes could run as their own process, doesnt this mean that they are also out of libbitcoinkernel?
19:32:47 <gribble> https://github.com/bitcoin/bitcoin/issues/24230 | indexes: Stop using node internal types and locking cs_main, improve sync logic by ryanofsky · Pull Request #24230 · bitcoin/bitcoin · GitHub
19:32:49 <laanwj> or renamed to something else if there's a better match for the remaining functionality
19:34:00 <cfields> I think it's useful to look at the file list to get an idea of how carl's working: https://github.com/bitcoin/bitcoin/pull/24304/files#diff-4cb884d03ebb901069e4ee5de5d02538c40dd9b39919c615d8eaa9d364bbbd77R832
19:34:23 <cfields> dongcarl: if I'm not mistaken, you started by globbing everything into there, then move things out piece-by-piece.
19:34:26 <dongcarl> lightlike: So in my "vision quest" branches, I've found that if we merge the prune blocker PR, then we can drop the blockfilterindex, and then we can rearchitect GetUTXOStats to not unconditionally depend on the coinstatsindex, then we don't have any indices in libbitcoinkernel
19:34:45 <laanwj> huh nice
19:35:26 <dongcarl> Yes! It's actually quite satisfying to see every bulk of change culminate in the removal of a .cpp file in the _SOURCES list :-)
19:36:24 <cfields> there are obviously some things that don't belong in that list, but are currently pulled in by something. those are basically the TODOs. util/asmap.cpp as a good example, should be moved out, but that presumably requires some refactoring first.
19:36:43 <laanwj> asmap seems decidedly P2P related
19:36:58 <cfields> right
19:37:23 <laanwj> it might be useful as an external library for some P2P purposes in itself, but that's a whole other topic :)
19:37:28 <provoostenator> p2p is not considered kernel I guess
19:37:39 <laanwj> right
19:38:12 <dongcarl> Nope P2P is not considered part of the kernel
19:38:27 <dongcarl> However, for stage 1, we are including the mempool
19:38:38 <MarcoFalke> Would it be possible to link libbitcoinkernel into bitcoind from the beginning (in #24230)?
19:38:40 <gribble> https://github.com/bitcoin/bitcoin/issues/24230 | indexes: Stop using node internal types and locking cs_main, improve sync logic by ryanofsky · Pull Request #24230 · bitcoin/bitcoin · GitHub
19:38:52 <MarcoFalke> sorry, 24303
19:39:37 <MarcoFalke> This means that the SOURCES can be removed from libbitcoin_node?
19:39:57 <MarcoFalke> (Maybe I should leave this as a code review comment)
19:40:09 <dongcarl> I explored doing that, and there's no clear hierarchy between our internal .a libs and libbitcoinkernel
19:40:18 <lightlike> for asmap, there is jnewbery's #22910 which, as a side-effect, might result in being able to remove the dependency
19:40:20 <gribble> https://github.com/bitcoin/bitcoin/issues/22910 | net: Encapsulate asmap in NetGroupManager by jnewbery · Pull Request #22910 · bitcoin/bitcoin · GitHub
19:40:54 <dongcarl> MarcoFalke: But I think that's a great idea worth exploring later on when we've decoupled more things!
19:41:07 <cfields> lightlike: aha, +1. sounds like that's very possible.
19:41:33 <dongcarl> Oh I think I had an easier fix for asmap in my branches :-)
19:42:11 <dongcarl> I think overall, we should also make some developer notes on how to code in a way that doesn't introduce too many dependencies/coupling
19:42:55 <dongcarl> Anyway, that's probably a topic for another day
19:42:59 <MarcoFalke> Couldn't the hirarchy issue be solved by linking libbitcoinkernel in between every .a lib?
19:43:26 <laanwj> we have another (probably short) topic to go, might want to wrap up
19:43:51 <dongcarl> MarcoFalke: I think the brute-force way is just to add it to the top of LDADD for all binaries, but that doesn't seem "right" to me
19:44:01 <dongcarl> I'm all done! We can move on
19:44:05 <dongcarl> Thanks all
19:44:28 <laanwj> thank you
19:44:47 <laanwj> #topic Discontinue release notes wiki (MarcoFalke)
19:44:47 <core-meetingbot`> topic: Discontinue release notes wiki (MarcoFalke)
19:44:49 <provoostenator> So this bitcoin-chainstate binary won't actually do anything right?
19:44:56 <provoostenator> It just makes sure we don't break the build.
19:44:56 <MarcoFalke> Yeah, so we introduced the wiki back when no release notes were written in pull requests. They were written before a release. Obviously that approach isn't sustainable, and we switched to writing release notes when the code was written.
19:45:08 <MarcoFalke> So I am thinking if we still need the wiki
19:45:20 <laanwj> there's still organization + editing work left
19:45:22 <achow101> We still use the wiki for finishing up release notes during the RC process
19:45:23 <dongcarl> provoostenator: I'll answer after this topic
19:45:28 <MarcoFalke> IIRC last time there were only a few minor typo fixes and other minor edits
19:45:39 <laanwj> we definitely dont' want a PR for every little typo fix
19:45:40 <jonatack> Quite a bit of editing happens in the wiki, I did a fair amount
19:45:57 <MarcoFalke> My thinking is that edits will need review either way
19:46:27 <laanwj> yes
19:46:31 <provoostenator> But maybe a wiki is more suitable for just letting people change things, check the history, and revert if needed?
19:46:34 <laanwj> but that's possible to do post-hoc for documentation
19:46:50 <laanwj> i do think a wiki is a better fit in general for documents than PRs
19:46:56 <laanwj> yes
19:47:02 <jonatack> Some was rewriting/fixups, and some was moving similar notes together / reorganizing IIRC
19:47:18 <laanwj> also the wiki can only be edited by organization members, so we don't really have to be afraid of vandalism
19:47:40 <prayank> laanwj: agree and had shared this a few months back
19:48:07 <prayank> agree with: i do think a wiki is a better fit in general for documents than PRs
19:48:09 <laanwj> in any case i don't see a strong reason to move away from the wiki approach, at least for major releases
19:48:22 <MarcoFalke> ok
19:48:55 <laanwj> so it's not so much about writing the release notes (though some need to be written) but more about combining, ordering, and the final touches
19:49:14 <laanwj> it's really inconvenient to do that cooperatively in PRs
19:49:52 <MarcoFalke> Ideally, we'd do all of that over the year and not last minute
19:50:06 <laanwj> some stuff always needs to be done last minute
19:50:16 <laanwj> but yes, doing more in sync with the code is of course better
19:50:17 <prayank> engineers
19:51:01 <MarcoFalke> At least I've been trying to do that (#24068, ...)
19:51:03 <gribble> https://github.com/bitcoin/bitcoin/issues/24068 | doc: Rework 14707 release notes by MarcoFalke · Pull Request #24068 · bitcoin/bitcoin · GitHub
19:51:20 <laanwj> good!
19:52:13 <laanwj> any other topics?
19:54:20 <jonatack> Subjecting release note edits to the review process seems daunting (to me :D)
19:54:46 <michaelfolkson> +1
19:55:11 <laanwj> i mean what could work is to have a separate repo with higher throughput than the usualy review process, and doesn't mind the noise, but that's effectively a wiki then
19:55:50 <MarcoFalke> It doesn't need to be a separate repo. If someone fixes a typo in the release notes, the pull can be merged by the first maintainer that sees it
19:56:00 <laanwj> also: i can't stress this enough please don't write too many release notes, it's not documentation, only a list of changes, it can refer to the actual documentation
19:56:16 <laanwj> i don't like how much spam that implies
19:56:17 <MarcoFalke> It is not like we need 37 ACKs and wait a week to fix a typo
19:56:31 <laanwj> i really dislike PRs that just fix a typo
19:56:32 <MarcoFalke> ok, that's a good point
19:56:58 <laanwj> definitely not going to merge them faster :)
19:57:18 <MarcoFalke> I am mostly worried about a last-minute rewrite of the release notes in the wiki (that introduce errors), but no one notices until after release
19:57:29 <laanwj> well, watch the changes then
19:57:49 <MarcoFalke> I mean "last-minute"
19:57:53 <laanwj> i'm not particularly afraid of that tbh
19:58:02 <MarcoFalke> ok
19:58:13 <MarcoFalke> Heh, let's end the meeting
19:58:30 <laanwj> people in the org don't usually do stupid stuff, but sure, it's good to pay attention, especially before merging them back to the branch
19:58:38 <warren> Would it be harmful to point at a webpage for the latest release notes instead of being part of the distribution?
19:59:05 <laanwj> i think having them (eventually) part of the distribution is fine
19:59:31 <provoostenator> And having the full archive of release notes in the source code is useful too.
19:59:39 <laanwj> webpages tend to disappear etc
20:01:05 <laanwj> i mean who knows we'll lose the lawsuit and bitcoincore.org disappears :p just kidding i guess but good to keep things self-contained
20:01:42 <laanwj> #endmeeting