14:00:23 <achow101> #startmeeting 14:00:25 <b10c> hi 14:00:29 <TheCharlatan> hi 14:00:33 <hebasto> hi 14:00:34 <achow101> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark 14:00:35 <sr_gi[m]> hi 14:00:38 <ryanofsky> hi 14:00:39 <brunoerg> hi 14:00:40 <kevkevin> hi 14:00:41 <instagibbs> hi 14:00:42 <cfields> hi 14:00:44 <furszy> hi 14:01:27 <achow101> There are no preproposed meeting topics this week. Any last minute ones to add? 14:02:13 <achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon) 14:02:27 <maxedw> hi 14:02:29 <sr_gi[m]> That's me 14:04:27 <sr_gi[m]> We've been compiling a list of simulations to run, writing down design decision so we can re-evaluate if needed down the line and see what has been considered. I've been updating the simulator and started to simulate some of them. The PR has also been brought up to date with the pending feedback. Gleb is working on a rebase of the whole Erlay implementation so some things can also be tested with real nodes in a warnet-like environment, 14:04:27 <sr_gi[m]> plus also reviving his simulator to run cross sims 14:05:08 <sr_gi[m]> There has also been some fuzzing by marko pointing out bugs to fix 14:05:12 <sr_gi[m]> I think that's it 14:05:40 <achow101> #topic Kernel WG Update (TheCharlatan) 14:05:41 <marcofleon> I'm looking to fuzz more once the rebase is done. And still wrapping my head around some of the design stuff 14:05:49 <TheCharlatan> Skipped the last few updates, so I'll do a drop of what I've been working on. 14:05:54 <TheCharlatan> I opened some more PRs for de-duplicating and simplifying logic for potential future users of the lib. 14:06:03 <TheCharlatan> Moving the final flush before shutdown to the ChainstateManager destructor: #31382 . This simplifies the tear-down procedure for the library significantly. 14:06:05 <gribble> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan ÷ Pull Request #31382 ÷ bitcoin/bitcoin ÷ GitHub 14:06:12 <TheCharlatan> Make the cache size calculations easier to use for kernel users: #31483 14:06:13 <gribble> https://github.com/bitcoin/bitcoin/issues/31483 | kernel: Move kernel-related cache constants to kernel cache by TheCharlatan ÷ Pull Request #31483 ÷ bitcoin/bitcoin ÷ GitHub 14:06:24 <TheCharlatan> After seeing the recent demand for better script debuggers, I was thinking how the kernel library might be useful for this in the future. It seems like btcdeb is not really usable for external projects, or projects extending the script interpreter. 14:06:33 <TheCharlatan> I added a debug callback in the kernel C API that hooks into the script interpreter and can provided a trace of the execution of a script here: https://github.com/TheCharlatan/bitcoin/commit/997c2ccc920adb0d1c9d8e82dbe94374cfb3c78b 14:06:38 <TheCharlatan> The hooks are gated by a macro, so users would have to compile with `ENABLE_SCRIPT_DEBUG`. 14:06:51 <TheCharlatan> This might be more viable than btcdeb for these kind of users, since only the interpreter itself would have to be changed for supporting new functionality, leaving changing the output of the debugger entirely up to the user. It could also be used to better test some of the internals of the interpreter. 14:08:16 <sipa> hi 14:08:24 <TheCharlatan> Lastly, I'd like to point out the RFC PR #31425, which checks that the static libbitcoinconsensus can be compiled for 32bit riscv bare metal. 14:08:25 <gribble> https://github.com/bitcoin/bitcoin/issues/31425 | RFC: Riscv bare metal CI job by TheCharlatan ÷ Pull Request #31425 ÷ bitcoin/bitcoin ÷ GitHub 14:09:10 <TheCharlatan> that's all 14:09:15 <sipa> TheCharlatan: does it test anything beyond compilation? 14:09:56 <TheCharlatan> no, but that could be added through qemu 14:10:02 <sipa> i see 14:11:17 <cfields> neat 14:12:04 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa) 14:12:07 <sipa> hi 14:12:29 <sipa> #31363 remains the thing to review at this point 14:12:33 <gribble> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa ÷ Pull Request #31363 ÷ bitcoin/bitcoin ÷ GitHub 14:13:03 <sipa> i've also opened a successor 31444, which adds interfaces for mining, eviction, and rbf diagram comparison to the TxGraph class 14:13:12 <instagibbs> #31444 14:13:14 <gribble> https://github.com/bitcoin/bitcoin/issues/31444 | cluster mempool: add txgraph diagrams/mining/eviction by sipa ÷ Pull Request #31444 ÷ bitcoin/bitcoin ÷ GitHub 14:14:26 <sipa> there remains one critical piece of logic at the TxGraph layer before the full cluster mempool code can be rebased on it (#28676), namely exposing an interface to deal with (too big) reorgs, as it is possible that reorgs merge the entire mempool together into a single cluster, and we need to do *something* in that case (we can't just reject them like RBFs) 14:14:30 <gribble> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar ÷ Pull Request #28676 ÷ bitcoin/bitcoin ÷ GitHub 14:15:12 <sipa> that said, there is enough code in 31363 and 31444 that deserves review, and it's complete with a simulation test that i think covers most if not all of the behavior we want from it 14:16:56 <sipa> in particular, i'm quite happy with how the test simulates mempool changesets: the transactions are stored in shared_ptrs, so to start a changeset, the simulation graph is just copied, on abort it's deleted, on commit it replaces the main graph 14:17:12 <sipa> that's it from me, unless there are questions/comments 14:17:42 <instagibbs> appreciate the additional context provided by newest PR, im finding it a bit difficult to do a deep review without the whole thing 14:18:16 <sipa> would it help to have a writeup of what txgraph's responsibility is, and what the hard problems it solves are? 14:18:48 <sipa> in order to get review in before the full thing is PRed? 14:19:07 <instagibbs> Hard to say, I'm having difficulty judging if the API is sensible if I don't actually see it used in anger 14:19:20 <instagibbs> some things are obviously correct, others im unsure 14:19:22 <sipa> fair point 14:20:14 <sipa> i guess i can't really help with that apart from getting closer to a point where 28676 can be rebased 14:20:59 <instagibbs> will circle back after looking at newest PR 14:21:34 <achow101> #topic MuSig2 WG Update (achow101) 14:21:46 <achow101> A couple fuzz crashes were found in #31247 which have been fixed 14:21:47 <gribble> https://github.com/bitcoin/bitcoin/issues/31247 | psbt: MuSig2 Fields by achow101 ÷ Pull Request #31247 ÷ bitcoin/bitcoin ÷ GitHub 14:22:07 <achow101> Err rather #31244 14:22:09 <gribble> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 ÷ Pull Request #31244 ÷ bitcoin/bitcoin ÷ GitHub 14:22:20 <achow101> The next PRs to review are still #31242 and #31243 14:22:23 <gribble> https://github.com/bitcoin/bitcoin/issues/31242 | wallet, desc spkm: Return SigningProvider only if we have the privkey by achow101 ÷ Pull Request #31242 ÷ bitcoin/bitcoin ÷ GitHub 14:22:24 <gribble> https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 ÷ Pull Request #31243 ÷ bitcoin/bitcoin ÷ GitHub 14:22:51 <achow101> #topic Legacy Wallet Removal WG Update (achow101) 14:23:04 <achow101> In reviewing #30328, we've been finding some additional migration edge cases, and further edge cases in the PRs to fix those edge cases. 14:23:08 <gribble> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 ÷ Pull Request #30328 ÷ bitcoin/bitcoin ÷ GitHub 14:23:15 <achow101> There's now #31423, #31451, and #31452 opened for those. Any of these PR is the thing to review. 14:23:17 <gribble> https://github.com/bitcoin/bitcoin/issues/31452 | wallet: Migrate non-HD keys to combo() descriptor by achow101 ÷ Pull Request #31452 ÷ bitcoin/bitcoin ÷ GitHub 14:23:18 <gribble> https://github.com/bitcoin/bitcoin/issues/31451 | wallet: migration, avoid loading legacy wallet after failure when BDB isnt compiled by furszy ÷ Pull Request #31451 ÷ bitcoin/bitcoin ÷ GitHub 14:23:19 <gribble> https://github.com/bitcoin/bitcoin/issues/31423 | wallet: migration, dont create spendable wallet from a watch-only legacy wallet by furszy ÷ Pull Request #31423 ÷ bitcoin/bitcoin ÷ GitHub 14:23:27 <achow101> These edge cases aren't additional scripts that should be migrated, just different wallet configurations that caused migration failures or could be migrated in a better way. 14:23:36 <achow101> So already migrated wallets don't need to worry 14:23:47 <sipa> ah good 14:23:48 <achow101> Lastly, #30328 has been getting review and is being updated to be clearer on why it is doing some things 14:23:51 <gribble> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 ÷ Pull Request #30328 ÷ bitcoin/bitcoin ÷ GitHub 14:24:56 <achow101> IsMine has been reported to be very confusing to reviewers so I've been trying to make it clearer as to why the replacement code is correct 14:25:33 <achow101> #topic Multiprocess WG Update (ryanofsky) 14:25:40 <ryanofsky> hi 14:25:49 <ryanofsky> There's a backlog of PRs in #31098 that have one or two acks and could use another review to get unstuck. These are needed to get IPC mining features enabled in the next release 14:25:51 <gribble> https://github.com/bitcoin/bitcoin/issues/31098 | Stratum v2 via IPC Mining Interface tracking issue ÷ Issue #31098 ÷ bitcoin/bitcoin ÷ GitHub 14:26:28 <ryanofsky> #31318 (2 acks) #31346 (2 acks) #31196 (2 acks) #31197 (2 acks) #30437 (stale ack) #31375 (concept ack only) 14:26:31 <gribble> https://github.com/bitcoin/bitcoin/issues/31318 | Drop script_pub_key arg from createNewBlock by Sjors ÷ Pull Request #31318 ÷ bitcoin/bitcoin ÷ GitHub 14:26:33 <gribble> https://github.com/bitcoin/bitcoin/issues/31346 | Set notifications m_tip_block in LoadChainTip() by Sjors ÷ Pull Request #31346 ÷ bitcoin/bitcoin ÷ GitHub 14:26:34 <gribble> https://github.com/bitcoin/bitcoin/issues/31196 | Prune mining interface by Sjors ÷ Pull Request #31196 ÷ bitcoin/bitcoin ÷ GitHub 14:26:36 <gribble> https://github.com/bitcoin/bitcoin/issues/31197 | refactor: mining interface 30955 followups by Sjors ÷ Pull Request #31197 ÷ bitcoin/bitcoin ÷ GitHub 14:26:37 <gribble> https://github.com/bitcoin/bitcoin/issues/30437 | multiprocess: add bitcoin-mine test program by ryanofsky ÷ Pull Request #30437 ÷ bitcoin/bitcoin ÷ GitHub 14:26:39 <gribble> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky ÷ Pull Request #31375 ÷ bitcoin/bitcoin ÷ GitHub 14:27:12 <ryanofsky> Another thing that happened recently darosior has written rust code to be able to call the Chain interface over IPC. Can see his comments in #29409 14:27:16 <gribble> https://github.com/bitcoin/bitcoin/issues/29409 | multiprocess: Add capnp wrapper for Chain interface by ryanofsky ÷ Pull Request #29409 ÷ bitcoin/bitcoin ÷ GitHub 14:27:28 <ryanofsky> And that's all for me 14:28:00 <TheCharlatan> The rust wallet is very cool :) 14:28:09 <fanquake> I guess all the bugfix PRs in https://github.com/chaincodelabs/libmultiprocess/pulls should also be added to #31098 ? 14:28:10 <gribble> https://github.com/bitcoin/bitcoin/issues/31098 | Stratum v2 via IPC Mining Interface tracking issue ÷ Issue #31098 ÷ bitcoin/bitcoin ÷ GitHub 14:28:39 <fanquake> As well as any build failures / other issues (if the plan if to ship this on by default) i.e like #31455 14:28:40 <gribble> https://github.com/bitcoin/bitcoin/issues/31455 | multiprocess: build failure on Alpine with depends & `DEBUG=1` ÷ Issue #31455 ÷ bitcoin/bitcoin ÷ GitHub 14:28:57 <ryanofsky> Yes that's a good point I can do that 14:29:11 <ryanofsky> There's a lot that needs to come together 14:29:29 <TheCharlatan> will the release be macos and linux only? 14:30:25 <fanquake> Does our code-signing for macOS need any accomodations for multiprocess? i.e some entitlement to spawn other bins or similar 14:30:41 <ryanofsky> Unless I get windows support together in time I think so. There's an issue in the libmultiprocess repo saying what needs to be done but I haven't started that yet 14:30:57 <TheCharlatan> ok 14:32:02 <ryanofsky> fanquake, pretty sure that's not true. If that's the case the wrapper executable would also have problems 14:32:53 <fanquake> Ok, great if that doesn't need any other changes 14:32:55 <achow101> It doesn't seem like there's an entitlement for that. But the other bins will also need to be codesigned 14:33:32 <ryanofsky> In worst case first multiprocess release would just be linux only which is probably ok 14:34:08 <achow101> presumably we'd ship both multiprocess and monolithic for a while 14:34:35 <ryanofsky> well the multiprocess release should include both sets of binaries 14:34:58 <ryanofsky> (long discussion about that in #30983) 14:34:59 <gribble> https://github.com/bitcoin/bitcoin/issues/30983 | RFC: Multiprocess binaries and packaging options ÷ Issue #30983 ÷ bitcoin/bitcoin ÷ GitHub 14:35:04 <sipa> i think it would be good to try to end up with just a single type eventually 14:35:41 <sipa> if multiprocess can do everything that normal builds can, there is no need to keep supporting more configurations longer 14:36:06 <sipa> but not as long as there compatibility issues or other hassles with it of courde 14:36:06 <achow101> ok, will read through the discussion in 30983 14:36:20 <ryanofsky> sipa, i think biggest issue there is performance. gui and wallet interfaces are not really optimized to work well over ipc, but they could be 14:36:21 <sipa> ryanofsky: thanks, will rrad 14:36:38 <sipa> huh, that surprises me a bit 14:37:30 <ryanofsky> i think they are mostly just doing a lot of stupid things that add latency. if you run functional tests with ipc there is a definite slowdown 14:38:50 <achow101> #topic package relay WG Update (glozow) 14:39:01 <achow101> glozow says "WeâÂÂre making steady progress on #31397, and I would like to find additional reviewers for #31385." 14:39:05 <gribble> https://github.com/bitcoin/bitcoin/issues/31397 | p2p: track and use all potential peers for orphan resolution by glozow ÷ Pull Request #31397 ÷ bitcoin/bitcoin ÷ GitHub 14:39:06 <gribble> https://github.com/bitcoin/bitcoin/issues/31385 | package validation: relax the package-not-child-with-unconfirmed-parents rule by glozow ÷ Pull Request #31385 ÷ bitcoin/bitcoin ÷ GitHub 14:40:04 <achow101> Anything else to discuss today? 14:43:02 <achow101> #endmeeting