16:00:04 <fjahr> #startmeeting 
16:00:04 <corebot`> fjahr: Meeting started at 2026-02-05T16:00+0000
16:00:05 <corebot`> fjahr: Current chairs: fjahr
16:00:06 <corebot`> fjahr: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:07 <corebot`> fjahr: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:08 <corebot`> fjahr: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:11 <darosior> oh, hi
16:00:14 <fjahr> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sliv3r__ sr_gi tdb3 theStack TheCharlatan vasild
16:00:14 <fjahr> willcl-ark
16:00:14 <janb84> hi
16:00:15 <dzxzg> hi
16:00:19 <hebasto> hi
16:00:19 <kevkevin> hi
16:00:23 <dzxzg> willcl-ark
16:00:24 <hodlinator> hi
16:00:24 <furszy> hi
16:00:25 <vasild> hi
16:00:30 <stickies-v> hi
16:00:33 <fjahr> There is one pre-proposed meeting topic this week. Any last minute ones to add?
16:00:38 <Murch[m]> Hi
16:01:10 <lightlike> hi
16:01:16 <pinheadmz> yo
16:01:56 <kanzure> hi
16:02:11 <vasild> Just a note, for more visibility: a private broadcast tracking issue for the followups: https://github.com/bitcoin/bitcoin/issues/34476 end-of-message
16:02:23 <cfields> hi
16:02:36 <sipa> hi
16:02:42 <fjahr> Oh, our first WG leader arrived :D
16:02:43 <fjahr> #topic Net Split WG Update (cfields)
16:03:03 <cfields> I was distracted by the boost::signals2 replacement this week, still no net split update :(
16:03:18 <cfields> I swear I'll have an update one of these days :)
16:03:18 <jonatack> hi
16:03:29 <eugenesiegel> hi
16:03:29 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:04:02 <sipa> Focus remains #34257, which I think is ready for review.
16:04:04 <corebot`> https://github.com/bitcoin/bitcoin/issues/34257 | txgraph: deterministic optimal transaction order by sipa · Pull Request #34257 · bitcoin/bitcoin · GitHub
16:04:09 <andrewtoth> hi
16:04:27 <sipa> And I think it's important to have in 31.0, so we don't need to change mempool ordering in subsequent releases.
16:04:46 <sipa> So is #34023, which is also ready.
16:04:51 <corebot`> https://github.com/bitcoin/bitcoin/issues/34023 | Optimized SFL cluster linearization by sipa · Pull Request #34023 · bitcoin/bitcoin · GitHub
16:05:14 <sipa> I'm working on #34138, and I think with those 3, if they don't get split up further, we can call cluster mempool *DONE*.
16:05:16 <corebot`> https://github.com/bitcoin/bitcoin/issues/34138 | Cluster mempool: more accurate cost model for SFL by sipa · Pull Request #34138 · bitcoin/bitcoin · GitHub
16:05:23 <sipa> That's it for me.
16:05:24 <fjahr> Someone should add #34023 to the milestone :)
16:05:26 <corebot`> https://github.com/bitcoin/bitcoin/issues/34023 | Optimized SFL cluster linearization by sipa · Pull Request #34023 · bitcoin/bitcoin · GitHub
16:05:38 <instagibbs> ive been absent lately, will get to reviewing the ordering pr soon
16:05:43 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:06:33 <andrewtoth> getting some review on #34165, that's it from me.
16:06:37 <corebot`> https://github.com/bitcoin/bitcoin/issues/34165 | coins: don't mutate main cache when connecting block by andrewtoth · Pull Request #34165 · bitcoin/bitcoin · GitHub
16:07:33 <sipa> andrewtoth: will review more soon
16:07:40 <andrewtoth> sipa: thank you!
16:07:53 <fjahr> Ok, not seeing Fuzzing, Kernel or Silent Payments, if I missed someone please speak up now or after the topic
16:07:57 <fjahr> #topic v31 feature freeze upcoming in 3 weeks
16:08:04 <fjahr> - Release schedule: #33607
16:08:05 <corebot`> https://github.com/bitcoin/bitcoin/issues/33607 | Release Schedule for 31.0 · Issue #33607 · bitcoin/bitcoin · GitHub
16:08:14 <fjahr> Milestone: https://github.com/bitcoin/bitcoin/milestone/74
16:08:33 <fjahr> Anything to add or remove? Not that I could do that but I hope somebody will ;)
16:09:07 <andrewtoth> #34329 - we are releasing silent payments, but there are no debug logs. Without this it will be difficult to help users troubleshoot. It will also let us collect statistics.
16:09:11 <corebot`> https://github.com/bitcoin/bitcoin/issues/34329 | rpc,net: Add private broadcast RPCs by andrewtoth · Pull Request #34329 · bitcoin/bitcoin · GitHub
16:09:32 <furszy> you meant private broadcast
16:09:51 <furszy> silent payments is another monster
16:09:56 <abubakarsadiq> hi
16:10:05 <andrewtoth> #33512 fixes lots of unnecessary warnings when running with high dbcache values, since we flush a lot now and dont clear
16:10:08 <corebot`> https://github.com/bitcoin/bitcoin/issues/33512 | coins: use number of dirty cache entries in flush warnings/logs by l0rinc · Pull Request #33512 · bitcoin/bitcoin · GitHub
16:10:14 <andrewtoth> furszy: thanks yes that's what i meant
16:11:06 <willcl-ark> hi
16:11:29 <marcofleon> hi
16:11:43 <marcofleon> I have a late proposed meeting topic
16:12:09 <marcofleon> what's the hashtag again? #proposetopic...
16:12:11 <fjahr> marcofleon: noted
16:12:41 <fjahr> Anyone else want to add something to the v31 milestone or has other comments on the release?
16:13:07 <fjahr> marcofleon: I think it doesn't work during the meeting, I am the bot you have to talk to now
16:13:52 <marcofleon> haha deal
16:14:54 <sipa> [6~[6~[6~[5~[6~OAOAOAOAOAOA
16:15:03 <furszy> yes sipa, agree
16:15:04 <fjahr> ok...
16:15:13 <marcofleon> are we moving on to next topic?
16:15:13 <fjahr> #topic late proposed meeting topic (marcofleon)
16:15:29 <marcofleon> ah there it is. Sorry in advance for the wall of text
16:15:35 <sipa> (kartograf made the machine with my irc client on swap trash...)
16:15:41 <marcofleon> I’ve been thinking about erlay quite a bit and want to see what others think. I’m leaning toward a NACK, with the information I have. I’m not convinced that the tradeoffs are worth it. As far as I understand:
16:16:03 <marcofleon> Pros: More tx relay (full relay) outbound connections for a less than proportional increase in data sent/received. We could double the full relay outbound connections from 8 to 16 without doubling the bandwidth.
16:16:13 <marcofleon> Cons: Latency across the network increases. In some cases in the simulations, latency almost doubled. Also, the changes to the P2P code that Erlay requires are fairly extensive aka added complexity.
16:16:25 <marcofleon> There is work being done in #28463 on increasing block-relay-only connections. I think the eventual goal there would be to have 8 of these connections. It’s not clear to me that having any more than 8 full relay really provides the network with a big benefit. We already have pretty good tx censorship resistance and so it seems like focusing on the block relay only connections for better eclipse attack protection is
16:16:25 <marcofleon> more beneficial. I’m open to changing this conclusion.
16:16:28 <corebot`> https://github.com/bitcoin/bitcoin/issues/28463 | p2p: Increase inbound capacity for block-relay only connections by mzumsande · Pull Request #28463 · bitcoin/bitcoin · GitHub
16:16:46 <marcofleon> Basically just looking to gauge the project and try to figure out where we stand on this. Of course we don’t need to have answers right now, but at some point (this year?) would be nice to get a priority ACK/NACK. If we generally agree that we won’t be moving forward with it in the foreseeable future, then it would be good to remove any Erlay related code that’s been merged and focus on increasing block relay
16:16:46 <marcofleon> connections. If we do end up deciding that the tradeoffs are worth it and that developer time should be spent on Erlay, then I would be happy to work on/review it and make it happen. It’s definitely an elegant idea
16:18:20 <sipa> It's a good discussion to bring up. I agree we should decide to either move forward and pioritize, or cancel entirely.
16:19:54 <instagibbs> would a fresh issue with the discussion be a good place to start it? a recap may be helpful to those (raises hand) who haven't been paying close attention to the evolution of hte idea over time
16:20:07 <marcofleon> No need for a conclusion now, my point was just to bring it up for now. We can keep it in mind
16:20:28 <lightlike> to be fair, erlay became more relevant with the recent attempts to censor transactions by preventing them from reaching miners (Knots). Although the threshold for that is already quite low (~10%)
16:20:59 <marcofleon> instagibbs: A rehash of conceptual discussion in an issue could be good
16:21:14 <furszy> sr_gi[m] ^^
16:21:20 <fjahr> Agree good to have the discussion, I was also wondering what the recent progress was.
16:21:30 <Murch[m]> I think AJ's proposal to sync the top of mempools is also relevant in the context
16:22:00 <willcl-ark> sr_gi[m]: has been re-running simulations recently too IIUC, which could be good to have presented in such a recap issue
16:23:17 <stickies-v> lightlike: i think the new private broadcast mechanism might also be useful there to more aggressively broadcast transactions?
16:23:18 <sipa> i think a fresh issue with conceptual discussion, trade-offs, and recent developments would be good
16:23:48 <sr_gi[m]> Hi
16:23:50 <sipa> stickies-v: that seems largely orthogonal to me, as it's just about the initial announcement
16:24:12 <marcofleon> nice, that sounds good. Yeah we can get recent updates there too. I know its a big project and simulations and testing are a big part of it, so its important to be thorough
16:24:47 <sipa> the mempool sync idea may matter - with that, we can perhaps tolerate a lower guarantee on reachability after fanout + recon, if it'll be fixed up later with mempool sync
16:24:49 <stickies-v> but being able to announce it to more peers seems like it should help with reaching more miners?
16:24:56 <marcofleon> My thoughts were based on the simulations I saw last year, maybe something has changed
16:25:05 <stickies-v> (haven't thought this through, just popped in my head)
16:25:40 <sr_gi[m]> I've been rebasing the code recently after private broadcast was merged. I agree with marcofleon that we should have a general decision on whether move forward with it or cancel. I'm happy to do a refresher on all the tradeoffs and pending things if people are interested, and push forward if there is interest in reviewing the code
16:26:41 <marcofleon> sounds good to me
16:27:11 <marcofleon> We can open a fresh issue then. Thanks everyone
16:27:35 <fjahr> Thanks marcofleon! Anything else to discuss?
16:29:01 <fjahr> #endmeeting