16:00:24 <achow101> #startmeeting 
16:00:24 <corebot> achow101: Meeting started at 2025-07-03T16:00+0000
16:00:25 <corebot> achow101: Current chairs: achow101
16:00:26 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:27 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:28 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:32 <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:34 <hebasto> hi
16:00:37 <cfields> hi
16:00:37 <johnny9dev> Hi
16:00:38 <laanwj> hi
16:00:41 <abubakarsadiq> hi
16:00:42 <lightlike> hi
16:00:42 <sr_gi[m]1> hi
16:00:44 <pinheadmz> hi
16:00:46 <stickies-v> hi
16:00:46 <achow101> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:00:46 <janb84> hi
16:00:56 <danielabrozzoni> hi
16:01:06 <brunoerg> hi
16:01:20 <achow101> #topic Erlay WG Update (sr_gi, gleb)
16:01:35 <vasild> hi
16:02:56 <sipa> hi
16:03:51 <dergoegge> hi
16:03:56 <instagibbs> hi
16:03:58 <Murch[m]> Hi
16:04:03 <sr_gi[m]1> It seems the propagation time issue I found last week may be what was making erlay times too good to be true. I've been re-running the simulations for small (50 nodes) and medium-size (200 nodes) networks. I'm currently re-working part of the warnet simulations so they can handle bigger networks (500 nodes is the most I've done, but the sims are a bit unreliable)
16:04:18 <pablomartin4btc> hi
16:04:28 <sr_gi[m]1> My goal is having the sims for all of them in the upcoming days so I can report back hopefully next week, and start moving forward
16:05:09 <sr_gi[m]1> That's it on my end
16:05:25 <achow101> #topic Fuzzing WG Update (dergoegge)
16:05:37 <dergoegge> Found 2 bugs on PRs with fuzzamoto in the last two weeks. One really shallow one in the erlay sketch deserialization code and one in the cluster mempool PR. The mempool bug specifically is a nice example for the complex inputs that fuzzamoto can generate.
16:05:46 <dergoegge> Also implemented a “netsplit” oracle, which already found a minor issue, fixed by instagibbs here: https://github.com/bitcoin/bitcoin/pull/32869 (would be nice to get some review on that)
16:05:56 <dergoegge> More updates (and links to the above): https://gist.github.com/dergoegge/0f732c440c19d02cf5eb6059ee90147c
16:06:22 <sipa> nice!
16:07:02 <dergoegge> (that's it on my end)
16:07:22 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:07:45 <sipa> hi
16:08:11 <sipa> i think both #31553 and #30605 are really close
16:08:14 <corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
16:08:16 <corebot> https://github.com/bitcoin/bitcoin/issues/30605 | Cluster linearization: separate tests from tests-of-tests by sipa · Pull Request #30605 · bitcoin/bitcoin · GitHub
16:08:40 <sipa> the past week some extra benchmarks are tests were added, but i don't expect many further changes
16:08:51 <glozow> hi
16:09:02 <instagibbs> try not to rebase on master if possible :P
16:09:38 <sipa> after that, the txgraph API will be largely complete, and i think we can start focusing on getting parts of the full cluster mempool implementation (#28676) in
16:09:40 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
16:09:59 <glozow> sipa: would the plan be to do that PR all together?
16:10:08 <glozow> (all of 28676)
16:10:36 <sipa> unsure, i assume it contains some amount of preparatory work that can be split off
16:11:16 <sipa> but the bulk, adding the cluster tracking, and switching out the mempool tracking, will need to be one PR I think (or at least a sequence of PRs that are all expected to go into the same release)
16:12:01 <glozow> makes sense
16:12:09 <sipa> that's it for me, unless more questions
16:12:42 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:12:45 <abubakarsadiq> On the process of re-reviewing  #31553,  https://github.com/bitcoin/bitcoin/pull/31553/commits/938e86f8fecd65ca90b97e6cf896f8c59fb590ba
16:12:45 <abubakarsadiq> I like the test one transaction forming huge cluster by spending them. and then in trim we don't just evict it alone.
16:12:45 <abubakarsadiq> we evict others, I think that should not be the case?
16:12:47 <corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
16:14:08 <sipa> abubakarsadiq: an optimal eviction algorithm could avoid that, but the trim algorithm is really just a best-effort of what we can accomplish in O(n log n)
16:14:48 <sipa> with proper linearization we could do a lot better - but the whole point of trim is that it can work with much larger numbers of transactions than what fit in a cluster
16:14:48 <achow101> #topic cluster mempool still
16:15:53 <abubakarsadiq> yep, could just throw txs in compact block reconstruction txs with a bound if thats the case.
16:16:05 <sipa> right
16:17:06 <abubakarsadiq> Also I think if we evict children first, we could avoid that but the current best effort algorithm is better in terms of incentive compatibility I think
16:17:18 <sipa> i'm not too worried about this, in practice i think the amount of oversized would-be clusters formed by reorged will be pretty small in non-attack scenarios
16:17:35 <instagibbs> most clusters are singletons after all
16:17:35 <abubakarsadiq> 👍
16:17:38 <sipa> and it costs creating a block to do something deliberately crazy
16:18:46 <sipa> abubakarsadiq: we're not restricted to the current Trim algorithm too; we could experiment with better algorithms later, or even have multiple algorithms depending on the size (e.g. have a medium-size trim algorithm that works acceptably fast for say ~200 transactions, but not 5000, for which we can still fall back to the current Trim one)
16:19:03 <sipa> but those don't affect the API, so wouldn't block further cluster mempool progress
16:19:14 <abubakarsadiq> yes please
16:19:32 <sipa> now back to your regularly scheduled MuSig2
16:19:57 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:20:11 <achow101> #31244 is probably rfm, otherwise, no updates
16:20:14 <corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:20:23 <achow101> #topic orphan resolution WG Update (glozow)
16:21:19 <glozow> I've been working on benchmarks for #31829, and have been chatting with sipa about potentially baking number of inputs into the dos score
16:21:21 <corebot> https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
16:21:39 <instagibbs> for the eraseforblock case?
16:21:40 <glozow> Worst case EraseForBlock times were pretty bad (if you have tons of transactions each spending hundreds of inputs all conflicting with the block)
16:21:48 <glozow> yeah, I'm getting 35ms on my machine
16:22:25 <sipa> EraseForBlock, but also EraseForPeer could trigger most (but not all) of the same work, which is potentially triggerable by non-miners
16:23:19 <instagibbs> due to outpoint map?
16:23:38 <glozow> Yes. EraseForBlock is slightly worse because it has the loop that builds the set of wtxids to erase (each of the 1750 wtxids is added ~180 times). And then it has to erase all of those entries from the outpoints map
16:24:52 <instagibbs> 👍
16:24:55 <glozow> The current ideated formula is that "announcement count" becomes 1 + floor(vin.size() / 10) for each tx. So the first 9 inputs are "free" and this limit is hopefully not relevant to normal transactions
16:26:03 <sipa> the vin.size()/10 would be deduplicated across peers, while the 1 part isn't
16:26:18 <sipa> as each tx's inputs only appear once in the outpoint index
16:27:55 <glozow> right that part is similar to the memusage metric
16:28:56 <glozow> Since last week I've also added sipa's simulation fuzzer + a few small tweaks and tests
16:29:04 <glozow> that's all the updates
16:29:45 <achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:30:11 <johnny9dev> Not much this week on QML work. bitcoin-core/gui-qml#450 got merged and hebasto and pinheadmz are making good progress on  bitcoin-core/gui-qml#472.
16:30:11 <johnny9dev> Thats all for now
16:30:13 <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:30:19 <corebot> https://github.com/bitcoin-core/gui-qml/issues/472 | Rebase gui-qml on bitcoin/bitcoin, include qt6 and cmake by pinheadmz · Pull Request #472 · bitcoin-core/gui-qml · GitHub
16:30:30 <achow101> Any other topics to discuss?
16:31:13 <l0rinc> I have a mempool related question regarding https://github.com/bitcoin/bitcoin/pull/32827#issue-3186436123
16:31:47 <l0rinc> do we need to keep the mempool stats up-to-date when the mempool is still empty? My understanding is that when it becomes empty we definitely need to keep the fee estimation state updated, but not sure if that's necessary during IBD. And if I try skipping `MempoolTransactionsRemovedForBlock` notification for the resulting empty vector of removals, I'm getting a test failure and need some help in deciding if the test shows a representative behavior
16:31:47 <l0rinc> or not - would be nice if we could avoid adding another callback into the validation queue...
16:31:49 <achow101> #topic mempool in ibd
16:33:01 <glozow> Is the question whether the fee estimator needs to know about every `MempoolTransactionsRemovedForBlock`?
16:33:29 <l0rinc> yes, in case of no removals
16:33:57 <l0rinc> as is the case as far as I can tell during IBD before any mempool activity
16:33:59 <abubakarsadiq> l0rinc: is it the fee estimator test that is failing?
16:34:28 <l0rinc> it's feature_fee_estimation
16:34:50 <glozow> I think this is the only way the fee estimator updates `txHeight`
16:35:20 <glozow> Is this slowing IBD down though? Doesn't this happen on a background thread?
16:35:28 <abubakarsadiq> shouldn't it be no-op when their is no data on mempool, is their a measurable improvement from skipping that?
16:36:05 <jonatack> hi
16:36:27 <l0rinc> glozow: it's blocking the queue, as furzsy sais:
16:36:32 <l0rinc> > First quick glance it seems that if the mempool is empty; we could avoid calling removeForBlock entirely. Which will save us from adding another callback into the validation queue too, which will leave space for processing another block during ibd.
16:36:32 <l0rinc> > Yet, that was a fast check. Should check who is using the MempoolTransactionsRemovedForBlock event.
16:36:38 <l0rinc> https://github.com/bitcoin/bitcoin/pull/32730#discussion_r2140931183
16:38:03 <l0rinc> We don't have to resolve it here, if anyone has insights, please add it to the PR - otherwise I will keep the MempoolTransactionsRemovedForBlock call for empty txs_removed_for_block as well
16:38:10 <abubakarsadiq> glozow: yes, we update `nHeight` after we are done with ibd and update the fee estimator stats for the first time it recorded data is marked as confirmed because of a new block.
16:38:40 <glozow> so the fee estimator doesn't do anything during IBD?
16:40:17 <abubakarsadiq> yes it does not, it has to see transaction enter mempool first.
16:41:11 <glozow> I meant to ask if the fee estimator gated on IBD?
16:41:28 <glozow> if its functions are gated*
16:42:34 <glozow> nvm, can look at this later
16:42:42 <abubakarsadiq> the updates are redundant, we don't do anything and can be avoided I think.
16:42:51 <abubakarsadiq> I started looking at it in https://github.com/bitcoin/bitcoin/pull/32748
16:43:58 <l0rinc> thanks, that's it from me
16:44:36 <achow101> Any other topics?
16:46:22 <achow101> #endmeeting