16:00:08 <achow101> #startmeeting 
16:00:08 <corebot> achow101: Meeting started at 2025-05-15T16:00+0000
16:00:09 <corebot> achow101: Current chairs: achow101
16:00:10 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:11 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:12 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:13 <TheCharlatan> hi
16:00:16 <hebasto> hi
16:00:16 <brunoerg> hi
16:00:17 <achow101> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto hodlinator 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
16:00:18 <sipa> hi
16:00:19 <Murch[m]> hi
16:00:29 <pinheadmz> Hi
16:00:37 <lightlike> Hi
16:00:44 <johnny9dev> hi
16:00:46 <eugenesiegel> hi
16:00:47 <achow101> There is 1 preproposed meeting topic, any last minute ones to add?
16:00:58 <stickies-v> hi
16:01:06 <marcofleon> hi
16:01:41 <achow101> #topic Kernel WG Update (TheCharlatan)
16:02:00 <hodlinator> hi
16:02:17 <maxedw> Hi
16:02:21 <TheCharlatan> Had a PR review club yesterday on #32317.
16:02:23 <corebot> https://github.com/bitcoin/bitcoin/issues/32317 | kernel: Separate UTXO set access from validation functions by TheCharlatan · Pull Request #32317 · bitcoin/bitcoin · GitHub
16:02:38 <TheCharlatan> I also discussed some future optimizations that this might enable today, e.g. reducing the scope of cs_main, running block validation in parallel.
16:02:44 <furszy> hi
16:03:00 <TheCharlatan> #32427 has already received a bunch of conceptual feedback, thanks for that!
16:03:02 <corebot> https://github.com/bitcoin/bitcoin/issues/32427 | (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store by TheCharlatan · Pull Request #32427 · bitcoin/bitcoin · GitHub
16:03:53 <TheCharlatan> I'd be interested in hearing some more opinions on if this could allow us to get rid of much of the reindexing logic
16:04:01 <rkrux> hi
16:04:29 <TheCharlatan> though some have raised concerns in the PR already that reindexing also encompasses recovering from block file corruption.
16:04:44 <laanwj> hi
16:05:06 <TheCharlatan> that's all for today
16:05:22 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:05:42 <sipa> 31444 got merged (yay!), #31553 is next to review
16:05:44 <corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
16:06:30 <sipa> On the research front, we found a counterexample to our earlief belief that the SFL linearization algorithm always makes progress: https://delvingbitcoin.org/t/spanning-forest-cluster-linearization/1419/6
16:07:00 <sipa> That's unfortunate, though I don't think it has much practical impact - it's still far better than what we have, and logistically much more useful than the 1989 paper algorithm.
16:07:29 <sipa> So my thinking remains to in the near future work on replacing the current algorithm with that.
16:08:14 <Murch[m]> What is the practical implication of that?
16:08:16 <sipa> To clarify: it's a randomized algorithm, and the "no progress" possibility boils down to forever making terrible choices, it doesn't mean an inability to make progress.
16:08:18 <abubakarsadiq> hi
16:08:28 <Murch[m]> Would that mean that some clusters just never get linearized or just that some cycles would be wasted?
16:08:40 <Murch[m]> Okay
16:09:37 <sipa> In all examples found, there is something like a 50-80% chance of making progress anyway, whenever you're in such a (very rare) potential-not-making progress state.
16:09:48 <sipa> But of course, there may exist examples for which the situation is worse.
16:10:03 <sipa> 50-80% chance per step
16:10:25 <sipa> That's it for me.
16:10:53 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:10:59 <achow101> Been addressing review and rebasing #31622
16:11:03 <corebot> https://github.com/bitcoin/bitcoin/issues/31622 | psbt: add non-default sighash types to PSBTs and unify sighash type match checking by achow101 · Pull Request #31622 · bitcoin/bitcoin · GitHub
16:11:05 <achow101> PRs to review are still #31622 and #31244
16:11:06 <corebot> https://github.com/bitcoin/bitcoin/issues/31622 | psbt: add non-default sighash types to PSBTs and unify sighash type match checking by achow101 · Pull Request #31622 · bitcoin/bitcoin · GitHub
16:11:07 <corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:11:19 <achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:11:29 <abubakarsadiq> TheCharlatan: is #32427 at a stage you need testing?
16:11:31 <corebot> https://github.com/bitcoin/bitcoin/issues/32427 | (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store by TheCharlatan · Pull Request #32427 · bitcoin/bitcoin · GitHub
16:11:47 <johnny9dev> bitcoin-core/gui-qml#448 was merged this week.
16:11:47 <johnny9dev> I'm continuing work on bitcoin-core/gui-qml#450 with just the list of recipients in the Review page remaining to be completed
16:11:47 <johnny9dev> Christoph has proposed a solution for initial loading state using a "skeleton" design pattern. He opened up a discussion at https://github.com/BitcoinDesign/Bitcoin-Core-App/issues/155 and has a prototype to go with it.
16:11:49 <corebot> https://github.com/bitcoin-core/gui-qml/issues/448 | Introduce Coin Selection page by johnny9 · Pull Request #448 · bitcoin-core/gui-qml · GitHub
16:11:50 <corebot> https://github.com/bitcoin-core/gui-qml/issues/450 | Add Multiple Recipients option to the Send form by johnny9 · Pull Request #450 · bitcoin-core/gui-qml · GitHub
16:12:41 <fanquake> johnny9dev: is the qml branch going to be rebased onto master at some point? I'd have assumed you'd want cmake + qt6 now that it's available
16:13:06 <johnny9dev> Thats the current thought
16:13:32 <Murch[m]> johnny9dev: I was a bit surprised at the sparse information in the coin control table, it looks like it is just amount and address. Is this going to be extended or is this the intended final state?
16:13:33 <hebasto> it makes more sense after restoring Android builds
16:13:37 <johnny9dev> I haven't had much slack time to experiment but I am very curious still about alternative deployments that have been discussed
16:14:14 <pinheadmz> fanquake: I am working on that rebase
16:14:20 <pinheadmz> (For fun!)
16:14:40 <pinheadmz> 400 commits and hundreds of conflicts. Mostly multiprocess interface and build system
16:15:05 <sipa> pinheadmz: i'm impressed, can i ask what sort of thing you would consider not fun?
16:15:37 <pinheadmz> Changing diapers ?
16:16:02 <pinheadmz> Anyway. Once rebase is done idk what to do with it (force push to qml master?)
16:16:16 <sipa> pinheadmz: are you trying to maintain the commit history? i can imagine that squashing parts or even all of it would make this a lot easier
16:16:22 <johnny9dev> @murch: there is a discussion on github for a more final implementation. https://github.com/BitcoinDesign/Bitcoin-Core-App/issues/155
16:16:27 <pinheadmz> I am not
16:16:41 <pinheadmz> I actually used a script to filter out pairs of revert commits, etc
16:16:56 <johnny9dev> Sorry, https://github.com/BitcoinDesign/Bitcoin-Core-App/issues/153 for Coin Control details
16:17:25 <Murch[m]> ah, was gonna say that it seems unrelated
16:17:37 <Murch[m]> Thanks, I’ll take a look
16:17:40 <pinheadmz> I think ideally qmlgui ends up with bitcoin/bitcoin as a git sub module
16:17:51 <pinheadmz> Or muktiprocess something something
16:18:21 <johnny9dev> I agree with that
16:18:29 <hebasto> ^^ as pointed by darosior
16:19:54 <TheCharlatan> abubakarsadiq, marcofleon has written a differential fuzz test for the PR. Further testing would also be appreciated, what did you have in mind?
16:21:02 <achow101> #topic communication about Core's vision for relay policy from current contributors (darosior)
16:21:17 <darosior> Hi everyone. My proposal for the OP_RETURN standardness rule change has been severely mischaracterized online. This has led to genuine concerns from Bitcoin enthusiasts about the change itself, but also about Bitcoin Core. I do not think there is any ground for these concerns, but what is done is done. From my experience engaging with the community
16:21:18 <darosior> in the past weeks i think we should hold off the change for some time (if it's gonna be merged doesn't matter if it is now or in 2 weeks) and work on our communication. To this end i suggest we post on the website a broad view of how Bitcoin Core approaches relay policy, to be signed off by people working in this area of the codebase. It should be
16:21:18 <darosior> short, in the form of an executive summary. I think it would go a long way for people who heard about the drama but cannot afford to spend time digging on Github or the mailing list and interpret our technical discussions.
16:22:13 <achow101> similar to what instagibbs tried to write up last week?
16:22:18 <darosior> No
16:22:45 <achow101> or more generic?
16:23:08 <darosior> instagibbs' writeup was specific and technical, so much that it just confused people who aren't already familiar
16:23:09 <Murch[m]> It sounds like it would be more about the goals and approaches, not the concrete case
16:23:19 <darosior> Yes exactly
16:24:13 <cfields> hi... ircd troubles.
16:24:33 <darosior> cfields: got the logs?
16:24:47 <sipa> I'm generally supportive of putting some statement on the website to have something to point people to, though obviously it'll depend on the content.
16:25:00 <achow101> sipa: +1
16:25:08 <achow101> darosior: do you have a draft to share?
16:25:20 <darosior> I don't i wanted to take the temperature first
16:25:27 <cfields> darosior: no, I'll catch up from context and read logs later. thanks though.
16:25:30 <abubakarsadiq> @thecharlatan: I remember using py-bitcoinkernel for my mining research https://github.com/ismaelsadeeq/mining-analysis and it's a bit annoying I have to shutdown my bitcoind, so I am thinking whether it is at the stage I can reproduce try reproducing the research without shutting down bitcoind and halting other node activities I am running.
16:25:39 <Murch[m]> Having spent a bunch of time discussing online in the past couple weeks, I do think that we should talk less about the nuanced trade-offs and more about what our priorities are
16:25:47 <sipa> TheCharlatan, abubakarsadiq: stick to topic, please?
16:26:44 <willcl-ark> hi
16:27:33 <Murch[m]> Trying to convey the finer details exacerbated the amount of follow-up questions and results in finer grained misconceptions that take even more time to address. darosior’s idea sounds good to me.
16:27:53 <sipa> It's a bit of a challenge I think to do this, as Bitcoin Core contributors are an ill-defined group and I think few people are comfortable speaking for others. But I can imagine a statement from some maintainers/regular contributors of the form "We believe many contributors feel the goal of relay/mempool/... should be", so rather than "Bitcoin Core believes X should happen", it is an observation
16:28:00 <sipa> about current contributors' views
16:29:02 <darosior> That sounds good to me
16:29:48 <achow101> yeah, i'd prefer to have it be a statement from the contributors who sign off on it, rather than a statement from the project
16:30:35 <fanquake> How many signatures do you need for it to be viable for the website?
16:30:43 <darosior> i think we should be able to make statements from the problem, but this is a different discussion. A letter signed off by contributors in this area relayed on the website sounds good to me
16:30:47 <Murch[m]> achow101, sipa: Would such a personal statement still be published on bitcoincore.org?
16:31:10 <darosior> *from the project, sorry, not problem
16:31:53 <darosior> I think a short explainer of why the binaries released by the project on the website are the way they are has absolutely its place on the website...
16:32:31 <achow101> Murch[m]: depends on the content, and if enough people sign it?
16:32:54 <darosior> I don't think it's the number of the signatures that matter, but who signs it
16:33:53 <stickies-v> if there's enough consensus (among core devs) to merge it, there should be enough consensus to put a website post up
16:33:54 <sipa> Hmm, I think I'm not getting my suggestion across well. I don't mean at all a personal statement by some/many people, individually signed by all.
16:34:07 <darosior> stickies-v: exactly
16:34:21 <achow101> darosior: sure, but we also don't want it to be perceived as a small group of people setting the direction of the project
16:35:02 <fanquake> sipa: yea I think I'm missing the difference between "We believe many contributors feel" & "Bitcoin Core believes X",
16:35:31 <pinheadmz> why imply anything? why wouldnt it be "we the undersigned believe..." ?
16:35:31 <darosior> achow101: the set of people that would make such a change a reality (by signing off the PR) is not large. That's just the reality
16:36:11 <sipa> fanquake: well for one it doesn't need to claim to be inclusive of all views
16:36:23 <sipa> but yeah, maybe there isn't that much of a difference
16:36:53 <fanquake> Sure. I guess in my mind, the view of the project is what we are shipping in the binaries
16:37:27 <darosior> fanquake: +1
16:37:28 <stickies-v> exactly this. if we ship based on rough consensus, we should be able to blog post based on rough consensus
16:37:56 <TheCharlatan> there could be a difference between what is shipped, and what people believe the direction of policy over the next few years should be.
16:38:30 <willcl-ark> So would this be an educational post, something like the compact blocks FAQ? Or more of a report, or just a "we the undersigned agree x" type of thing?
16:38:39 <darosior> TheCharlatan: yeah i think there is a true distinction between what is and what should be in the future. That's up for debate too in my opinion, but here i am suggesting we do the former
16:39:16 <stickies-v> sure, but 32406 specifically includes direction of policy by changing a default and deprecating the option, right?
16:39:27 <darosior> heh, true
16:39:40 <sipa> but even deprecation is not a promise, just an intent
16:39:55 <sipa> and as contributors and their views change, intent can change
16:40:01 <instagibbs> sipa +1
16:40:02 <darosior> willcl-ark: something akin to "what we've been up to, and why"
16:40:13 <sipa> darosior: i like that
16:40:22 <achow101> I think I'll have more/stronger opinions once there's something to review
16:40:23 <willcl-ark> darosior: ok. that sounds nice
16:40:40 <abubakarsadiq> I think there is something similar on the website https://bitcoincore.org/en/2015/09/01/open-letter/
16:40:41 <darosior> achow101: yeah, let me come up with a draft and we can reassess
16:40:44 <achow101> it's too early for abstract thought :p
16:41:21 <sipa> abubakarsadiq: wow, blast from the past :p
16:41:32 <darosior> By the way i think it would be nice if we published more PSAs about what we've been up to. But this one is most important now because of the recent controversy
16:41:41 <stickies-v> thank you for all your public work on this darosior (and others)
16:42:12 <darosior> stickies-v: thanks for the thanks, and sorry to have triggered this in the first place
16:42:28 <darosior> (although it was just unveiling resentment that was already there)
16:42:33 <achow101> Any other topics to discuss?
16:42:34 <sipa> darosior: *pew* (the sound of people shotting the messenger)
16:42:43 <darosior> lol
16:43:17 <cfields> I'm not sure what we're trying to accomplish here. My understanding is that the hate isn't coming so much from the change itself so much as the perception of how decisions are made and priorities are set. I'm not sure that "this is why we're doing X" is a constructive response to that?
16:43:35 <Murch[m]> Aye, I think we should generally think a bit more about public communication, and even how we support users of Bitcoin Core
16:43:40 <darosior> cfields: a decent part of misunderstanding is also coming from the change
16:44:13 <darosior> Murch[m]: i agree, topic for the next Coredev? Also happy to discuss it during an IRC meeting
16:44:52 <glozow> Light concept ACK to "here's the north star / what we've been doing and why." Also agree that perhaps communication about how decisions are made might be even more important
16:45:04 <Murch[m]> I’ve been told by several people in the past couple months that they wish there were a way to contact Bitcoin Core if one had questions or support issues, and others have recommended that we might find a couple contributors that do public relations or developer advocacy in some form.
16:45:09 <stickies-v> cfields: I was starting to type a similar response too, i think a lot of people have already heard a lot of the reasoning, but just fundamentally believe we / contributors / maintainers are evil or compromised and should not be trusted, and more reasoning may not convince them
16:45:20 <Murch[m]> E.g., by trying to talk more about the big picture
16:45:27 <sipa> cfields: i think having a place to describe motivations for a change can very much help with some misunderstandings i'm seeing (as opposed to needing individual contributors' social media posts, which can be hard to find, scattered, and easily drowned in noise)
16:45:29 <stickies-v> but i don't know how to solve that, and having a brief, easy-to-point to statement might still be a helpful addition
16:45:37 <Murch[m]> Someone actually recently approached me that they want to make some educational videos about Bitcoin Core
16:46:22 <Murch[m]> It certainly doesn’t sound like stuff that’s close to our heart, but we also can’t lose three weeks on a good chunk of developers every time someone misrepresents a situation
16:47:32 <achow101> stickies-v: if people believe that contributors are evil / compromised, I don't think any communication that we do would really change that opinion?
16:47:49 <darosior> Murch[m]: this is more than 3 weeks of time that is at stake. It should not be overstated but i think it shook the trust in Bitcoin Core to some extent.
16:48:01 <sipa> achow101: yes, but i think that's only a minority, and maybe not the most important one
16:48:07 <Murch[m]> darosior: Yeah, I agree
16:48:34 <darosior> achow101: this is not about convincing people that already made their mind but the silent majority of people that are currently hearing from only the side of "Core is evil"
16:48:40 <Murch[m]> achow101: I think the perception that we are compromised or misguided is only tenable, because the actual motivations are not understood
16:49:46 <darosior> And a lot of people that is important to not lose the trust of, don't have the time to dig up through dumpster fire Github threads and ML threads for our arguments
16:50:21 <TheCharlatan> yes, my impression from the past three weeks is that people genuinely don't understand why and how we're nudging ecosystem behaviour with policy.
16:50:43 <darosior> I am not saying that as a project we should address every single tin foil hat conspiracy out there, but we should at least have a statement about our vision out. Anyone genuine can hear them and read us. Right now they can only hear them.
16:51:02 <achow101> sure, I think writing a statement is fine, I just don't think that a dissuading people who have that opinion should necessarily be a goal
16:51:03 <Murch[m]> Yeah, the conversation being on Twitter, Nostr, Stacker News, Delving, the Mailing List, the podcast sphere, and probably a gazillion chats that we aren’t in, doesn’t help with getting our message out when we don’t feel that strongly about it, while the other side thinks the world is on fire
16:51:16 <abubakarsadiq> I think more communication is always welcome and beneficial, but I don’t believe it will prevent misclassification or incidents like the one caused by the recent policy change PR.
16:51:16 <abubakarsadiq> In an open-source project like this, some people will always complain or create noise when developers make a decision that doesn’t align with their views.
16:51:16 <abubakarsadiq> I’m not sure there’s a clear way to address that.
16:51:18 <achow101> but certainly explaining motivations may help to that effect
16:52:47 <Murch[m]> There also generally have been a few things that the community has felt very strongly about that Bitcoin Core has not addressed, so it’s just been piling up
16:53:51 <darosior> abubakarsadiq: we will never sway disingenuous people. There is still plenty of genuinely confused people out there to be swayed. I think a letter on the website is a very cost efficient way of working toward that goal.
16:53:56 <Murch[m]> Given that we are such a small group compared to the Bitcoin user base, more simply resources served highly visibly might significantly reduce our effort
16:54:16 <darosior> Murch[m]: yes, this is not about that specific issue. Resentment has been piling up and lack of communication is fueling it
16:54:55 <achow101> anyways, it seems like the next thing to do is to have something written to review
16:55:01 <stickies-v> i agree it's worth doing effort to provide resources to people genuinely trying to understand
16:55:01 <glozow> Producing more and more text that nobody reads is a bad strategy imo. It seems like we''re always thinking "if I just write one more post, they'll get it" and that's not true. I don't think we can win an information war unless we devote significant resources to becoming influencers long term. We have code to write, and they don't.
16:55:05 <achow101> that will probably help inform the questions about what the point is
16:55:28 <abubakarsadiq> +1 glozow
16:56:05 <darosior> glozow: this is not about writing one more blog post this is about writing the very first thing about it.
16:56:48 <Murch[m]> glozow: Yeah, what I’m tryìng to express is that we might want to communicate less often, but simpler and more visibly
16:57:02 <glozow> I think darosior, Murch, and many others have written a ton about op_return already. They are excellent and were worth the time. But who is the person who will be convinced by a bitcoincore.org post and not the ones you've already written?
16:57:31 <sipa> glozow: i think there may be some
16:57:31 <glozow> And how will they come across this post?
16:57:58 <darosior> glozow: I don't think an executive of a Bitcoin company will go read my thousand line detailed technical refutation of mostly tin foil hat stuff and made-up objections. They will read two paragraphs published officially on the Bitcoin Core website.
16:58:17 <Murch[m]> glozow: Yeah, I’m not talking about the spilt milk,  I’m thinking that in hindsight, e.g., darosior’s one long post was a much better at broadly addressing the issue than my ~200 posts
16:58:17 <glozow> Murch: that seems like a good strategy overall
16:58:29 <darosior> glozow: the same way they come across binaries. Somehow they find their way.
16:58:42 <Murch[m]> exactly what darosior said
16:59:20 <glozow> darosior: I don't think so. I think they message a dev or somebody dev-adjacent that they trust
16:59:21 <achow101> glozow: I think something that is jointly the opinion of multiple contributors will have more weight than the hundreds of separate posts arguing with specific people
16:59:47 <achow101> at least more easily pointed to as an opinion of several contributors to the project
17:00:06 <Murch[m]> Anyway, +1 on waiting with merging 32406, +1 on one or two simple statements of a few lines (that might take significant effort to craft) reserving the judgement after seeing the content ;)
17:00:21 <sipa> yeah, let's discuss when there is some text
17:00:30 <achow101> #endmeeting