14:00:15 <achow101> #startmeeting 14:00:16 <achow101> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi theStack TheCharlatan vasild 14:00:18 <sdaftuar> hi 14:00:18 <tdb3> hi 14:00:19 <b10c> hi 14:00:22 <glozow> hi 14:00:22 <brunoerg> hi 14:00:23 <Murch[m]> hi 14:00:25 <fjahr> hi 14:00:28 <sr_gi[m]1> hi 14:00:31 <lightlike> hi 14:00:33 <furszy> hi 14:00:40 <stickies-v> hi 14:01:03 <hebasto> hi 14:01:11 <achow101> There is one preproposed meeting topic, any last minute ones to add? 14:01:16 <willcl-ark> hi 14:01:23 <jonatack> hi 14:01:33 <fjahr> I will yapp on about assumeutxo one more time :) 14:01:42 <achow101> #topic package relay updates (glozow) 14:02:12 <glozow> #30110 still priority. It hasn't actually gotten any review comments yet, so I'm not thinking it'll be in 28.0 14:02:14 <gribble> https://github.com/bitcoin/bitcoin/issues/30110 | refactor: TxDownloadManager + fuzzing by glozow ÷ Pull Request #30110 ÷ bitcoin/bitcoin ÷ GitHub 14:02:40 <glozow> That's all for me 14:02:58 <achow101> #topic cluster mempool updates (sdaftuar) 14:03:19 <sdaftuar> cluster mempool is progressing! #30285 was merged a few days ago. #30286 is up next and has gotten some review already 14:03:21 <gribble> https://github.com/bitcoin/bitcoin/issues/30285 | cluster mempool: merging & postprocessing of linearizations by sipa ÷ Pull Request #30285 ÷ bitcoin/bitcoin ÷ GitHub 14:03:23 <gribble> https://github.com/bitcoin/bitcoin/issues/30286 | cluster mempool: optimized candidate search by sipa ÷ Pull Request #30286 ÷ bitcoin/bitcoin ÷ GitHub 14:04:04 <sdaftuar> happy to take questions but that is it from me 14:04:30 <achow101> #topic legacy wallet removal updates (achow101) 14:05:12 <achow101> Since 28.0 is coming up, I'd like to get https://github.com/bitcoin-core/gui/pull/824 and #30265 in. 14:05:14 <gribble> https://github.com/bitcoin/bitcoin/issues/30265 | wallet: Fix listwalletdir listing of migrated default wallets and generated backup files by achow101 ÷ Pull Request #30265 ÷ bitcoin/bitcoin ÷ GitHub 14:05:31 <achow101> these are more like bug fixes though so I think don't have to make the feature freeze deadline 14:06:05 <achow101> Otherwise, haven't gotten any review on the other PRs 14:06:28 <achow101> #topic Ad-hoc high priority for review 14:06:33 <theStack> hi 14:06:33 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 14:07:44 <sipa> hi 14:08:12 <achow101> #topic 28.0 release priorities 14:08:20 <achow101> Feature freeze is scheduled for this Monday 14:08:33 <achow101> anything we should add or remove to the milestone? 14:08:38 <fjahr> I know IâÂÂve been harping on about this for a while but since we are so close, it would be great if we could tag the remaining important Assumeutxo PRs for v28. #29519 already has two ACKs. #28553 would be necessary too and we had intense discussions over the last two days so I hope we can lay this to rest quickly now. Technicallyyyy both of these are fixing bugs in the existing assumeutxo feature (signet/testnet3) so I 14:08:39 <fjahr> donâÂÂt think they would necessarily even need to make it in before feature freeze. And then of course #30598àwhich technicallyyyy is updating chain params which is also something we usually do after feature freeze :p 14:08:40 <gribble> https://github.com/bitcoin/bitcoin/issues/29519 | p2p: For assumeutxo, download snapshot chain before background chain by mzumsande ÷ Pull Request #29519 ÷ bitcoin/bitcoin ÷ GitHub 14:08:42 <gribble> https://github.com/bitcoin/bitcoin/issues/28553 | validation: assumeutxo params mainnet by Sjors ÷ Pull Request #28553 ÷ bitcoin/bitcoin ÷ GitHub 14:08:43 <gribble> https://github.com/bitcoin/bitcoin/issues/30598 | assumeutxo: Drop block height from metadata by fjahr ÷ Pull Request #30598 ÷ bitcoin/bitcoin ÷ GitHub 14:08:46 <fjahr> Most importantly I think a lot of people have been involved in, improved and better understood assumeutxo over the last 6 months (again see #29616) and the vibe I have been getting from others is that there is agreement that the feature is ready for mainnet use, especially since setting an initial height at 840k is really low risk. 14:08:48 <gribble> https://github.com/bitcoin/bitcoin/issues/29616 | AssumeUTXO Mainnet Readiness Tracking ÷ Issue #29616 ÷ bitcoin/bitcoin ÷ GitHub 14:09:00 <achow101> https://github.com/bitcoin/bitcoin/milestone/66 14:09:52 <fjahr> Ah, I see the issue for #30598 was already added 14:09:54 <gribble> https://github.com/bitcoin/bitcoin/issues/30598 | assumeutxo: Drop block height from metadata by fjahr ÷ Pull Request #30598 ÷ bitcoin/bitcoin ÷ GitHub 14:10:04 <achow101> fjahr: added all 3 14:10:12 <fjahr> achow101: thank you! 14:10:44 <hebasto> the 28.0 milestone in the GUI repo -- https://github.com/bitcoin-core/gui/milestone/13 14:11:50 <achow101> fjahr: was that your assumeutxo topic? 14:11:50 <sipa> i'd really like to see #30043 in sooner than later, but it can use more review (unsure if before feature freeze is reasonable) 14:11:53 <gribble> https://github.com/bitcoin/bitcoin/issues/30043 | net: Replace libnatpmp with built-in PCP+NATPMP implementation by laanwj ÷ Pull Request #30043 ÷ bitcoin/bitcoin ÷ GitHub 14:12:40 <achow101> sipa: I think it might not make it for feature freeze 14:12:46 <achow101> maybe for 29.0? 14:12:57 <fjahr> achow101: yepp, nothing else to add 14:12:59 <sipa> achow101: agreed 14:13:41 <achow101> #topic Future of priority projects (achow101) 14:14:44 <achow101> At the last CoreDev, we had a discussion about priority projects. I recall that the general sentiment was that it was getting less effective since we moved to doing online polling and such. 14:15:21 <achow101> IIRC we concluded that for the next set of priority projects, we would determine them in person at the October CoreDev 14:15:33 <sipa> that would be my preference 14:15:37 <fjahr> I think this is something that is best discussed in an in-person meeting but as an idea: it might be an interesting experiment to see what happens to priority projects if there isnâÂÂt one champion but 2-3 instead. If there are not 2-3 people interested in or capable of championing for a project, then maybe itâÂÂs not a good fit (yet). 14:16:14 <achow101> So I think once we past feature freeze on Monday, the current priority projects will be cleared, and we'll not have any until next CoreDev 14:16:21 <sipa> fjahr: my view is that *any* vote for a priority project should mean "i commit to actively contributing/reviewing PRs related to this feature if it ends up winning" 14:16:44 <glozow> achow101: that makes sense to me 14:16:45 <fjahr> sipa: that would be ideal but doesn't seem to be the reality :/ 14:17:06 <sipa> fjahr: that seems to be a communication issue to me 14:17:34 <fjahr> maybe there should be the option or urge for people to not put in all of their votes if they don't want to do that 14:17:50 <fjahr> but best discussed in person probably.. 14:17:54 <sipa> fjahr: yeah 14:17:58 <jonatack> would contributors not attending coredev be asked for input? 14:19:07 <sipa> i think it makes sense to start proposals/nominations before coredev, and then continue permitting voting by org members after... but the benefit of actually having the fast interactive discussion in person seems evident to me 14:19:30 <fjahr> I guess these are different side of a spectrum on forming teams around a priority project, which I think would be a good direction for experimenting 14:19:42 <fjahr> *sides 14:20:00 <lightlike> i don't think that the voting modus has much to do with the effectiveness. I think if there aren't enough people who would be willing change what they will work on based on the outcome of the vote, the vote doesn't really make a difference. 14:21:54 <achow101> I think a big component of why it worked the first time was because we did it in person and the vote gave people the motivation to shill their projects and convince others to work on it while we were all in the same place 14:22:05 <jonatack> it could possibly furthermore be argued that both coredev and additional project management processes can be centralization pressures, to an extent. so while they can be more or less somewhat effective, my preference is more in the direction of ad hoc rather than process 14:22:07 <Murch[m]> I wouldnâÂÂt perceive it as a vote in that sense: itâÂÂs more of taking a census of what people intend to work on, and giving projects with a lot of contributors a focus in the meetings. 14:22:37 <fjahr> lightlike: I think sipa's point is less about the mode of voting but actually buy in from the voters 14:22:46 <achow101> jonatack: tbh this is pretty ad hoc. we're making up the process as we go :p 14:23:01 <jonatack> achow101: :) 14:23:44 <furszy> I think we should just take it as a public way of forming working groups with weekly updates on the most voted ones. 14:24:15 <achow101> anyways, the point is that we'll try something different for 29.0, and it will likely be centered around discussions that occur at CoreDev 14:24:42 <achow101> Any other topics? 14:26:17 <glozow> fwiw, I disagree that trying to communicate what our plans are to form working groups is centralization pressure. We can be decentralized without being disorganized. 14:26:35 <jonatack> achow101: sure. if/when in doubt, suggest less process over more. side benefit: more interesting, less mechanical meetings 14:27:03 <achow101> #endmeeting