14:00:24 <achow101> #startmeeting 14:00:28 <b10c> hi 14:00:30 <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 maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark 14:00:31 <hodlinator> hi 14:00:33 <sipa> hi 14:00:39 <nymius> hi 14:00:40 <vasild> hi 14:00:40 <jonatack> hi 14:00:43 <tdb3> hi 14:00:44 <brunoerg> hi 14:00:45 <instagibbs> hi 14:01:09 <achow101> There are no pre-proposed meeting topics this week. Any last minute ones to add? 14:01:20 <jarolrod> Hi 14:01:26 <theStack> hi 14:01:32 <dergoegge> can we get marcofleon added to the meeting ping list? 14:01:36 <fjahr> hi 14:01:45 <marcofleon> hi 14:02:10 <hebasto> hi 14:02:14 <achow101> dergoegge: marcofleon: added 14:02:22 <marcofleon> thanks 14:02:23 <dergoegge> cheers 14:02:52 <achow101> For future reference, I just copy-paste from https://github.com/bitcoin-core/bitcoin-devwiki/wiki/IRC-Meeting-Cheat-Sheet which should be editable by everyone in the org 14:03:12 <dergoegge> ah i see, thanks 14:03:22 <achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon) 14:03:42 <gleb> Hi 14:03:48 <willcl-ark> hi 14:04:20 <gleb> On erlay we currently have a list of design questions weâÂÂre discussing in the WG 14:05:06 <gleb> Im personally spending a bunch of time rebasing the full implementation 14:05:14 <gleb> Sergi is working on the simulations 14:05:20 <gleb> ThatâÂÂs it 14:05:27 <maxedw> hi 14:05:52 <achow101> #topic Fuzzing WG Update (dergoegge) 14:06:10 <glozow> hi. sorry iâÂÂm late 14:06:33 <dergoegge> no real update 14:06:33 <dergoegge> https://github.com/guidovranken/cryptofuzz/ was deleted 1 or 2 weeks ago and i'm not sure how we're gonna replace that wrt fuzzing secp 14:06:51 <instagibbs> oof 14:07:02 <achow101> why was it deleted? 14:07:26 <sipa> we had a student work on writing a libfuzzer-based harness for libsecp256k1 some time ago, which would be able to do more low-level things 14:07:33 <fanquake> the crypto fuzz maintainer nuked all his repos 14:07:34 <dergoegge> not entirely sure this is all we know: https://github.com/google/oss-fuzz/pull/12746 14:07:50 <sipa> it never progressed past being a prototype, but it'd be nice if someone picked it up 14:08:15 <dergoegge> sipa: cool! i think the cool thing about cryptofuzz was the differential oracle 14:08:25 <sipa> dergoegge: yeah, i'm aware 14:08:51 <dergoegge> we have a fork of cryptofuzz (latest commit afaik) but i would assume it's not trivial to maintain 14:08:52 <vasild> "In light of the EU Product Liability Directive and other speech criminalizations I am ceasing all my publications including FOSS contributions." 14:08:54 <furszy> hi 14:09:29 <achow101> yeesh 14:09:35 <fanquake> dergoegge: itâÂÂs missing my last upstream fix but otherwise up to date yea 14:09:43 <sipa> some portion of the kinds of things cryptofuzz could catch are also covered by wycheproof 14:09:54 <fjahr> dergoegge: does it make sense to put it under a core org? 14:10:16 <fanquake> not unless someone is planning to maintain it 14:10:17 <fjahr> at least until another, better maintained for emerges 14:10:49 <fjahr> for someone to start it needs to be available somewhere 14:11:34 <dergoegge> https://github.com/fanquake/cryptofuzz 14:11:46 <fjahr> that works 14:11:48 <cfields> hi 14:11:58 <dergoegge> fanquake: you're the maintainer now 14:12:19 <achow101> There appear to be other forks too:https://github.com/google/oss-fuzz/pull/12765#issuecomment-2520199032 14:12:26 <fanquake> If also suggest that if someone wants to re-add it to oss-fuzz, to bot re-add it to the bitcoin-core project, but keep it separate 14:13:02 <fanquake> As the majority of our build failures came from crypto-fuzz, but that isnâÂÂt needed for core, so would just break out build 14:13:06 <brunoerg> the MozillaSecurity fork seems active 14:13:37 <fanquake> So keeping it separate means our fuzzers donâÂÂt break when the secp cryptofuzz build does 14:14:27 <achow101> it seems like the libsecp folks are looking into it 14:14:29 <achow101> let's move on 14:14:42 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa) 14:14:51 <sipa> hi 14:15:13 <sipa> since last meeting i have opened #31363 14:15:14 <gribble`> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa ÷ Pull Request #31363 ÷ bitcoin/bitcoin ÷ GitHub 14:15:44 <instagibbs> how much work remains to get a glimpse of end to end usage 14:16:25 <sipa> it implements (part of) the "medium level" layer: sort of a whole-mempool representation of the transaction graph, but very stripped down in functionality (it knows only fees, sizes, dependencies, and represents transactions as abstract handle "Ref" objects, no txids, no ctransaction, ...) 14:17:06 <sipa> it's tested by a single simulation fuzz test, which compares the behavior of it with a naive reimplementation (mostly) which treats the entire mempool as a single depgraph 14:17:31 <sipa> instagibbs: you mean in terms of what is left to do at the txgraph level, or what is left for cluster mempool as a whole? 14:17:37 <instagibbs> latter 14:18:40 <sipa> so i'm working on extending txgraph to be fully featured (i have some non-pr'ed stuff that is ready already) so it provides enough functionality (specifically, it needs mining/eviction, and a way to deal with reorgs that might otherwise violate policy limits) 14:19:04 <sipa> after that, i think sdaftuar is planning to rebase #28676 on txgraph 14:19:08 <gribble`> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar ÷ Pull Request #28676 ÷ bitcoin/bitcoin ÷ GitHub 14:20:06 <sipa> then there are a few "optimizations" that we'll probably want soon, but aren't blockers for more progress on the mempool side (e.g. reducing memory usage for small clusters in txgraph, and a way to do background relinearization, ...) 14:20:13 <instagibbs> taking that as Two Weeks, thanks 14:20:20 <sipa> yeah, (tm) 14:20:39 <bitcoin-git> [bitcoin] maflcko opened pull request #31428: ci: Allow build dir on CI host (master...2412-ci-build) https://github.com/bitcoin/bitcoin/pull/31428 14:20:45 <sipa> in either case, 31363 is the thing to review now 14:21:06 <sipa> based on feedback, i'm happy to split off more parts, split off commits, ... whatever helps 14:22:24 <sipa> perhaps also an interesting update that won't affect things in the too near future: during bitcoin research week at chaincode, some researchers came up with an idea for how optimal cluster linearization may be doable in polynomial time 14:22:58 <glozow> sipa: do you think that algo would require a refactor? or could it just be an edit to cluster_linearize.h? 14:22:58 <sipa> depending on how things evolve there, the approach may end up being too slow to run inside our "relay-time" linearization logic, so it wouldn't really affect our guarantees or cluster size limit 14:23:08 <instagibbs> sipa interested to learn how th relaxation was shown to be optimal :) 14:23:23 <glozow> (assuming you want to incorporate it) 14:23:28 <sipa> but it may mean that a background relinearization can practically linearize everything optimally 14:23:35 <instagibbs> that's awesome 14:23:41 <sipa> glozow: it'd be pretty much a drop-in replacement for some code in cluster_linearize.h 14:23:51 <glozow> awesome! so it could be worked on in parallel 14:24:14 <sipa> instagibbs: i can give you a quick intuition, but let's do that after the meeting 14:24:18 <instagibbs> yeah offline 14:24:54 <sipa> that's it from me, unless sdaftuar still appears and has an update 14:25:07 <achow101> #topic MuSig2 WG Update (achow101) 14:25:15 <achow101> No updates, waiting for further review of #31242 and #31243 14:25:16 <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:25:18 <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:25:32 <achow101> #topic Legacy Wallet Removal WG Update (achow101) 14:25:44 <achow101> furszy found a few additional edge cases in migration and opened #31374 and #31378 to handle those. These are the current PRs to review. 14:25:46 <gribble`> https://github.com/bitcoin/bitcoin/issues/31374 | wallet: fix crash during watch-only wallet migration by furszy ÷ Pull Request #31374 ÷ bitcoin/bitcoin ÷ GitHub 14:25:48 <gribble`> https://github.com/bitcoin/bitcoin/issues/31378 | wallet: fix crash during migration due to invalid multisig descriptors by furszy ÷ Pull Request #31378 ÷ bitcoin/bitcoin ÷ GitHub 14:25:55 <achow101> #30328 has also gotten some review but is now waiting on 31374 and 31378 as those add tests that we want for 30328 14:25:58 <gribble`> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 ÷ Pull Request #30328 ÷ bitcoin/bitcoin ÷ GitHub 14:26:26 <achow101> #topic package relay WG Update (glozow) 14:27:03 <glozow> I've put up the next PR for making orphan resolution more robust by trying with all candidate peers, #31397. It is getting some review (thanks!!). We have a meeting 2h from now in #bitcoin-core-pr-reviews. I'm also happy to do a video call walkthrough if enough people are interested? lmk. 14:27:04 <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:27:37 <glozow> #28031 is rebased, and it includes the next step which would be to make `TxDownloadManager` internally thread-safe 14:27:41 <gribble`> https://github.com/bitcoin/bitcoin/issues/28031 | Package Relay 1/3: Introduce TxDownloadManager and improve orphan-handling by glozow ÷ Pull Request #28031 ÷ bitcoin/bitcoin ÷ GitHub 14:28:00 <glozow> The step after that would be orphanage protection and more thinking around how we can limit per-peer usage of orphanage 14:28:17 <glozow> Separately, #31385 may be of interest to mempool folks and users. It relaxes the "all unconf parents must be present" requirement for package validation. 14:28:18 <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:28:19 <sipa> glozow: i'm interested, but i've been quite out of the loop w.r.t. orphan handling... is there a writeup/pr/... that would help to get up to speed? 14:29:22 <glozow> sipa: I think https://github.com/bitcoin-core/bitcoin-devwiki/wiki/%5BP2P%5D-known-TxOrphanage-problems is the most comprehensive explainer for the problems we are looking at solving 14:29:32 <sipa> cool will have a look 14:30:36 <glozow> We have a (very old and quiet) group chat as a WG for this stuff so anybody feel free to lmk if you want to join. 14:31:49 <sipa> sure you can add me 14:32:14 <glozow> Great! 14:32:27 <glozow> That's it from me I think 14:32:44 <achow101> Any other topics to discuss? 14:34:37 <stevenroose> Does Core allow for changing the 100-block coinbase maturity in regtest? It is 100 blocks in regtest, right? 14:34:46 <achow101> #endmeeting