16:00:11 <glozow> #startmeeting 
16:00:11 <corebot> glozow: Meeting started at 2025-07-17T16:00+0000
16:00:12 <corebot> glozow: Current chairs: glozow
16:00:13 <corebot> glozow: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:14 <corebot> glozow: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:15 <corebot> glozow: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:21 <glozow> #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:22 <hebasto> hi
16:00:25 <maxedw> hi
16:00:29 <darosior> hi
16:00:30 <stickies-v> hi
16:00:38 <lightlike> Hi
16:00:38 <abubakarsadiq> hi
16:00:38 <theStack> hi
16:00:41 <sr_gi[m]1> hi
16:00:42 <glozow> I see 2 preproposed topics from darosior and fanquake - anything else to add / am I missing any?
16:00:51 <brunoerg> hi
16:01:12 <glozow> #topic Erlay WG Update (sr_gi, gleb)
16:02:58 <laanwj> hi
16:03:04 <sr_gi[m]1> I've been working on a small patch to Core so its easier to track propagation times. Opened a PR earlier this week but ended up closing it and going for a considerably smaller change that can just by patch on top of any branch to simulate, given the change seemed not to be useful outside that context.
16:03:05 <glozow> sr_gi?
16:03:32 <glozow> (nvm, I see your message now)
16:03:41 <sr_gi[m]1> I've reworked the Warnet simulations to use this, which have made them way less flaky
16:03:52 <sr_gi[m]1> PR to review remains the same #30116
16:03:54 <corebot> https://github.com/bitcoin/bitcoin/issues/30116 | p2p: Fill reconciliation sets (Erlay) attempt 2 by sr-gi · Pull Request #30116 · bitcoin/bitcoin · GitHub
16:04:04 <sr_gi[m]1> That it on my end
16:04:05 <johnny9dev> hi
16:05:21 <glozow> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:09:47 <johnny9dev> We created a new branch in the gui-qml project called "qt6" that is seeded with just the history of the qml folder. The pinhead did a PR into that branch with his CMake work to build it against a sub-module. bitcoin-core/gui-qml#475. The PR is quite comprehensive even including some github workflows for CI. I started reviewing it and found somethings to workthrough so thats my top priority going into the weekend. Afterwards I plan to
16:09:47 <johnny9dev> rebase all of my current work on top.
16:09:48 <johnny9dev> That is all from me.
16:09:49 <corebot> https://github.com/bitcoin-core/gui-qml/issues/475 | Add cmake, qt6, and bitcoin core submodule by pinheadmz · Pull Request #475 · bitcoin-core/gui-qml · GitHub
16:10:10 <glozow> #topic orphan resolution WG Update (glozow)
16:10:40 <glozow> #31829 is close, and will collect followups in #32941
16:10:43 <corebot> https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
16:10:45 <corebot> https://github.com/bitcoin/bitcoin/issues/32941 | p2p: TxOrphanage revamp cleanups by glozow · Pull Request #32941 · bitcoin/bitcoin · GitHub
16:11:02 <glozow> Does anybody else want to give WG updates? I skipped most of them based on attendance
16:12:23 <glozow> #topic Turn -natpmp on by default (darosior)
16:12:41 <darosior> Hi everyone, so very early on Bitcoin Core started shipping with NAT hole punching enabled by default with UPnP. This was disabled in 2015 following a discovery of an RCE in miniupnpc, the dependency Core used for UPnP, by laanwj present here. Disabled by default, NAT hole punching is not quite useful, and we eventually got rid of UPnP altogether
16:12:42 <darosior> due to the low quality of the miniupnpc dependency. NAT hole punching was re-implemented properly directly in Core for 29.0 by laanwj, using the PCP protocol with a NAT-PMP fallback. It was still disabled by default in 29. This is a higher quality implementation (properly reviewed, tested and fuzzed) of saner protocols. In comparison, our UPnP
16:12:42 <darosior> implementation involved parsing XML in C (and this was not fuzzed). Following 29, a number of contributors and power users helped in testing the feature. Testing demonstrated a reduction in functionality (unfortunately the less sane UPnP protocol is still much more widely supported than PCP and NAT-PMP). However it did not raise any concern with
16:12:42 <darosior> regard to our implementation. Because NAT hole punching is not really useful unless enabled by default, and because i think our implementation is now vetted enough i propose that we enable it by default in 30.0. What do you think?
16:13:57 <fanquake> #31663 
16:13:58 <corebot> https://github.com/bitcoin/bitcoin/issues/31663 | Enable PCP by default? · Issue #31663 · bitcoin/bitcoin · GitHub
16:14:01 <laanwj> Yes-In 29.0 we introduced our own NAT-PMP/PCP implementation, replacing often insecure miniupnp. To have more connectable nodes outside of datacenters, we'd eventually like to enable it by default. During the release cycle we've had people test it on many routers (see #31663), though it doesn't work on all, no real issues came up. So the proposal is to enable it by default for 30.0.
16:14:02 <corebot> https://github.com/bitcoin/bitcoin/issues/31663 | Enable PCP by default? · Issue #31663 · bitcoin/bitcoin · GitHub
16:15:17 <fanquake> #32159 also related
16:15:19 <corebot> https://github.com/bitcoin/bitcoin/issues/32159 | net, pcp: handle multi-part responses and filter for default route while querying default gateway by willcl-ark · Pull Request #32159 · bitcoin/bitcoin · GitHub
16:15:21 <laanwj> it's very possible to delay this by another version, if there's a good reason, but i think we have enough confidence in it now
16:16:05 <glozow> Seems pretty well-tested
16:16:08 <darosior> I agree. I think the benefits outweigh the risk now.
16:16:27 <laanwj> #32159 helps to parse very large routing tables on linux, which helps in the case of compelx routing (on the machine that runs bitcoind, not the router), but is not a requirement/real bugfix
16:16:28 <corebot> https://github.com/bitcoin/bitcoin/issues/32159 | net, pcp: handle multi-part responses and filter for default route while querying default gateway by willcl-ark · Pull Request #32159 · bitcoin/bitcoin · GitHub
16:17:14 <stickies-v> why is it "not really useful unless enabled by default"?
16:17:17 <darosior> Yeah it seems to be an improvement of the feature but not a requirement for 30.
16:17:54 <laanwj> if it can't find the default router, it'll default to not using it, which is the safe choice
16:18:31 <darosior> stickies-v: because it's useful only for users that can't play with the settings of their router to forward a port to their node. So if it is off by default, then it only helps user technical enough to tweak their bitcoind settings but not technical enough to be able to forward a port. I think the set of such users is very small.
16:18:49 <laanwj> stickies-v: because the idea is that it's effortless; if it requires people to set things up, it's less useful
16:19:11 <laanwj> e.g. if yu have to enable settings, it's slightly more work to forward a port yourself
16:19:28 <stickies-v> i think there's a huge gap between a user toggling a bitcoind setting vs playing with their router settings, so in my view this is still very useful even if disabled by default
16:19:38 <stickies-v> (note: i'm not arguing against disabling it by default)
16:19:44 <laanwj> okay, yes, probably
16:19:56 <laanwj> that's true
16:20:15 <stickies-v> s/disabling it by default/enabling it by default/
16:20:26 <darosior> I don't think so. I'd even think more people know about NAT traversal than about the specific NAT hole-punching protocols
16:20:57 <laanwj> also note that PCP/NATPMP only communicates with the default gateway (so, the closest router). Unlike UPNP it doesn't broadcast to the entire LAN
16:21:09 <sipa> +1 enabling by default; i think it's an obvious end goal of having nat traversal included in the software, and i don't think more testing will at this point change our understanding anymore
16:21:56 <laanwj> so it's private in that sense. if the router doesn't support it, it'll ignore the packet or return an error, both cases are handled.
16:23:03 <darosior> Ok, i think i'll make a PR and we can follow-up there?
16:23:05 <stickies-v> i haven't reviewed the code (or the reviewed or the review), but if we feel comfortable it's been tested enough then enabling it by default makes sense to me too
16:23:47 <laanwj> as i see it, the only reason to not enable it by default is that it could increase bandwidth usage for users that don't have -nolisten but rely on their IPv4 NAT router to shield the port. This is a brittle setup, though. E.g. they might already be automatically listening on Tor in that case
16:24:15 <laanwj> yes, let's do that
16:24:49 <sipa> if anything, i think the biggest concern might be large-scale emergent effects, like what happens if the set of reafhable nodes beces drawn from a very different distribution/topology (more home users, ...), but those are also effects that appear slowly following adoption, and there is little we can do to analyse them ahead of tr
16:25:08 <sipa> (phone typing, sorry for typos)
16:25:25 <jonatack> hi
16:25:30 <laanwj> more home users is a good thing for decentralization, anyhow. but yes, it could have unexpected effects.
16:26:04 <sipa> right, obviouslu!
16:27:08 <laanwj> also i'm confident it won't break the network. but it might, say, result in different choices to have to be made to get e.g. fastest download performance
16:27:24 <sipa> right
16:27:55 <laanwj> that's all i think-let's open a PR and continue discussion there
16:28:01 <darosior> Yeah
16:28:05 <sipa> sgtm
16:28:42 <glozow> #topic 29.1 fanquake
16:29:01 <fanquake> We are at ~3 months post 29.0; so about time to do a .1.
16:29:08 <fanquake> What should be the final round of backports are in #32863, which are ready for review.
16:29:10 <corebot> https://github.com/bitcoin/bitcoin/issues/32863 | [29.x] Backports by fanquake · Pull Request #32863 · bitcoin/bitcoin · GitHub
16:29:15 <fanquake> Prior backports also done in #32292, #32589 & #32810.
16:29:18 <corebot> https://github.com/bitcoin/bitcoin/issues/32292 | [29.x] Backports by fanquake · Pull Request #32292 · bitcoin/bitcoin · GitHub
16:29:20 <corebot> https://github.com/bitcoin/bitcoin/issues/32589 | [29.x] More backports by fanquake · Pull Request #32589 · bitcoin/bitcoin · GitHub
16:29:21 <corebot> https://github.com/bitcoin/bitcoin/issues/32810 | [29.x] More backports by fanquake · Pull Request #32810 · bitcoin/bitcoin · GitHub
16:29:24 <laanwj> will take a look
16:29:45 <fanquake> I think darosior has a suggestion for somethign to backport
16:29:58 <darosior> I'd like to get #32521. I think it's close to be merged in master (been through a few rounds of re-ACKing)
16:30:01 <corebot> https://github.com/bitcoin/bitcoin/issues/32521 | policy: make pathological transactions packed with legacy sigops non-standard by darosior · Pull Request #32521 · bitcoin/bitcoin · GitHub
16:30:50 <glozow> thanks, will review
16:31:21 <darosior> We see that people upgrade to .1 more than to .2 etc.. And i think adoption of this patch is important for the network to be upgraded if an activation of CC is attempted in the next few years
16:31:57 <darosior> And i'm afraid people will play shenanigans to slow down the upgrade to 30.0
16:35:55 <glozow> Anything else to discuss?
16:37:18 <glozow> #endmeeting