14:00:20 <achow101> #startmeeting 
14:00:23 <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 theStack TheCharlatan vasild
14:00:26 <stickies-v> hi
14:00:28 <hebasto> hi
14:00:28 <brunoerg> hi
14:00:31 <josie> hi
14:00:31 <furszy> hi
14:00:32 <instagibbs> hi
14:00:35 <Sjors[m]> hi
14:00:45 <Murch[m]> Hi
14:00:59 <glozow> hi
14:01:04 <achow101> There's 1 preproposed meeting topic today, any last minute ones to add?
14:01:10 <pinheadmz> hi
14:01:17 <maxedw> hi
14:01:21 <lightlike> hi
14:01:42 <sdaftuar> oh hi
14:01:46 <sipa> hi
14:01:49 <achow101> #topic package relay updates (glozow)
14:02:07 <theStack> hi
14:02:12 <glozow> I'm currently working on splitting the 2 refactoring commits out of #28970, and turning them into smaller changes for easier review.
14:02:13 <gribble> https://github.com/bitcoin/bitcoin/issues/28970 | p2p: opportunistically accept 1-parent-1-child packages by glozow · Pull Request #28970 · bitcoin/bitcoin · GitHub
14:02:29 <TheCharlatan> hi
14:03:10 <glozow> Trying to do it carefully as it feels a bit delicate. I'll have the PR up soon
14:03:48 <glozow> For package RBF, #29242 is helpful
14:03:52 <gribble> https://github.com/bitcoin/bitcoin/issues/29242 | Mempool util: Add RBF diagram checks for single chunks against clusters of size 2 by instagibbs · Pull Request #29242 · bitcoin/bitcoin · GitHub
14:04:07 <glozow> (It should also be helpful for cluster mempool, so 2x reason to review it!)
14:04:55 <glozow> Oh and #29306 looks close to rfm. That's all
14:04:58 <gribble> https://github.com/bitcoin/bitcoin/issues/29306 | policy: enable sibling eviction for v3 transactions by glozow · Pull Request #29306 · bitcoin/bitcoin · GitHub
14:05:21 <achow101> #topic cluster mempool updates (sdaftuar)
14:05:32 <sdaftuar> Hi, I pushed a rebase of the draft PR (#28676) this morning. This is still not a fully optimized implementation, and as a reminder the plan is still to re-engineer this to be awesome before moving the PR out of draft.
14:05:35 <gribble> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
14:05:46 <sdaftuar> In the meantime, interested reviewers can run this branch locally and collect their own benchmarking information if they’d like. Also, you can use the `getmempoolfeesize` rpc to produce a feerate diagram of the whole mempool, which is fun to look at.
14:05:59 <sdaftuar> For now, anyone looking to help can look at the test changes in the draft PR and start thinking about ways to improve what I’ve done (or fix tests I’ve broken) or add additional test coverage.
14:06:10 <sdaftuar> In a few weeks, I’ll likely start pinging people for help with changes to mini_miner and the wallet.
14:06:22 <sdaftuar> Currently, I’m starting do some initial benchmarking of how the current (unoptimized) implementation performs on historical data, and comparing with master.
14:06:31 <sdaftuar> These findings will be most interesting once we have a more fully optimized transaction graph module to use, but I can report some initial statistics on this unoptimized implementation to give everyone a sense of what we’re at right now, and to start answering some of the questions I posed in the OP of #28676.
14:06:33 <gribble> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
14:06:41 <sdaftuar> that's all for me
14:06:52 <achow101> #topic silent payments update (josie)
14:07:46 <josie> still heads down on reviewing and hashing out ideas for the libsecp module. based on that, i think id like to remove silent payments as a priority project for v28
14:08:11 <josie> last week i was optimistic that the work could happen in parallel, but after trying that for a week, i dont think its a good idea
14:08:45 <achow101> we can replace silent payments with legacy wallet removal since that has the next most votes
14:09:04 <glozow> ACK
14:09:05 <josie> yeah, seems like a better use of this meeting time
14:09:05 <TheCharlatan> +1
14:09:08 <brunoerg> ack
14:09:18 <sipa> sgtm
14:09:26 <stickies-v> +1
14:09:29 <achow101> #topic legacy wallet removal updates (achow101)
14:09:37 <sipa> that was fast
14:09:39 <TheCharlatan> :D
14:09:52 <achow101> The tracking issue is #20160
14:09:55 <gribble> https://github.com/bitcoin/bitcoin/issues/20160 | Proposed Timeline for Legacy Wallet and BDB removal · Issue #20160 · bitcoin/bitcoin · GitHub
14:09:58 <josie> haha great minds etc
14:10:02 <Murch[m]> ACK
14:10:18 <hebasto> ack
14:10:31 <achow101> Current pr to review is #26606
14:10:34 <gribble> https://github.com/bitcoin/bitcoin/issues/26606 | wallet: Implement independent BDB parser by achow101 · Pull Request #26606 · bitcoin/bitcoin · GitHub
14:10:38 <bitcoin-git> [bitcoin] furszy opened pull request #29586: wallet: default wallet migration, modify inconvenient backup filename (master...2024_wallet_migration_empty_wallet_backup_name) https://github.com/bitcoin/bitcoin/pull/29586
14:10:52 <furszy> add 29586 to the list.
14:10:59 <furszy> :p
14:11:40 <achow101> #topic Ad-hoc high priority for review
14:11:44 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
14:12:04 <hebasto> achow101: maybe make priorities as pinned gh issues again?
14:12:19 <b10c> hi
14:12:24 <achow101> hebasto: yes, will do that
14:12:42 <fanquake> don't think we can do that while we are testing rcs etc
14:13:05 <achow101> we can only have 3 pinned at a time
14:14:35 <achow101> #topic assumeutxo mainnet chainparams for v27 (fjahr)
14:14:57 <fjahr> Hi, so it was pretty much agreed to get the assumeutxo main net chainparams in for v27. Unfortunately there are still some blockers, some of which that were not tagged for v27. So there would still be some review work needed, namely #26045 and #29519
14:14:59 <gribble> https://github.com/bitcoin/bitcoin/issues/26045 | rpc: Optimize serialization disk space of dumptxoutset by aureleoules · Pull Request #26045 · bitcoin/bitcoin · GitHub
14:15:00 <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:15:08 <fjahr> Question is if people think we should delay the release for this so that v27 can have the main net chainparams included.
14:16:08 <fjahr> IMO the two PRs are not much work to review but there wasn't much action on them lately so it would need more peoples attention
14:16:15 <fanquake> I don't think so. It's a shame that the relvant PR's haven't gotten review, but clearly (bad) bugs are still being found, and I don't see any conclusion to the GUI discussion?
14:16:48 <fjahr> I think most people don't see the GUI as a blocker, aside from luke probably...
14:17:21 <lightlike> I think we should make a decision whether it's acceptable to just have entries added to chainparams, without having any distribution mechanism.
14:17:52 <instagibbs> lightlike to be clear, you mean not having some built in distribution mechanism?
14:18:13 <fanquake> Sure, we can disregard the GUI, but not all the unreviewed code and remaining bugs
14:18:13 <fjahr> The distribution mechanism was not part of James' proposal so if that is a blocker that should have been pointed out much earlier
14:18:28 <fanquake> and I don't see a pressing reason to rush all that in, post branch of, and an rc1 tag
14:18:29 <lightlike> not necessarily. we could also have consensus to put it on awbebsite, or maybe a torrent or whatever.
14:18:39 <sipa> imo without distribution mechanism it's not really usable for non-expert users anyway, so i don't think having the parameters set matters much?
14:18:40 <achow101> since the release cycle for 27.0 was much shorter than usual, I think it's okay that some things we thought could make it to 27.0 don't, and we can defer them to 28.0
14:19:12 <achow101> i'd rather not push the release back, otherwise we get back to the inconvenient release timings that we are trying to avoid
14:19:15 <fjahr> and there are good ways to get around it, I don't think we need to block people from using it like who set up a btcpayserver. They even had their own solution for this for some time.
14:20:09 <fjahr> Anyone can put it in a torrent or on a website
14:20:15 <sipa> fair point, these pre-packaged systems can make use of it
14:20:23 <instagibbs> I agree, but I don't think delaying release is the right move
14:20:27 <sipa> that may in practice mean that the distribution aspect is just handled by them
14:21:02 <fanquake> If delaying the release was ever going to happen, this should have been raised weeks ago, not after branch-off
14:21:07 <sipa> fanquake: agreed
14:21:34 <josie> +1
14:22:10 <fjahr> ok, still wanted to raise the point. I hope everyone help by keeping it in mind for v28. Thanks!
14:22:31 <achow101> Any other topics to discuss?
14:24:25 <achow101> #endmeeting