abubakarsadiq has quit [Quit: Connection closed for inactivity]
robszarka has joined #bitcoin-core-dev
szarka has quit [Ping timeout: 276 seconds]
mcey_ has joined #bitcoin-core-dev
emcy__ has quit [Ping timeout: 276 seconds]
szkl has quit [Quit: Connection closed for inactivity]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
sliv3r__ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
sliv3r__ has joined #bitcoin-core-dev
busy has joined #bitcoin-core-dev
fgarau has joined #bitcoin-core-dev
fgarau has quit [Ping timeout: 248 seconds]
Christoph_ has joined #bitcoin-core-dev
fgarau has joined #bitcoin-core-dev
fgarau has quit [Ping timeout: 244 seconds]
fgarau has joined #bitcoin-core-dev
<laanwj>
phantomcircuit: this kind of thing is aimed at long-running PRs (of which we have quite a few). when something big is merged into master, we want to re-test PRs that they still work as expected against the new maste
<laanwj>
it's not especially confusing to me, most of the CI tests happen merged against master
<laanwj>
which makes sense, with the eye on merging it, the hypothetical "state when this PR would be merged" is the one we care most about testing
busy has quit [Read error: Connection reset by peer]
Cory70 has quit [Quit: Client closed]
Cory70 has joined #bitcoin-core-dev
upekkha has quit []
upekkha has joined #bitcoin-core-dev
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] maflcko opened pull request #33001: test: Do not pass tests on unhandled exceptions (master...2507-test-actually-fail-on-failure) https://github.com/bitcoin/bitcoin/pull/33001
robszarka has quit [Quit: Leaving]
szarka has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
Christoph_ has quit [Quit: Christoph_]
jerryf_ has joined #bitcoin-core-dev
jerryf has quit [Ping timeout: 244 seconds]
jerryf_ is now known as jerryf
SpellChecker_ has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 244 seconds]
kevkevin has joined #bitcoin-core-dev
TheRec_ has quit [Ping timeout: 272 seconds]
kevkevin has quit [Ping timeout: 248 seconds]
instagibbs has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
Guest44 has joined #bitcoin-core-dev
Guest44 has left #bitcoin-core-dev [#bitcoin-core-dev]
<darosior>
#proposedmeetingtopic Turn -natpmp on by default
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 248 seconds]
<maflcko>
phantomcircuit: It is due to intermittent and non-intermittent CI issues that are fixed later in master. If you run the CI on the pull with one of those, you may never/rarely get a green CI, even though the code changes are usually perfectly fine.
<maflcko>
So merging master is the easiest workaround (the alternative would be to have devs rebase for basically no reason). Also, with any mutable CI logic in yaml files, it is actually impossible to not merge with with master, see https://github.com/bitcoin/bitcoin/pull/32203#issue-2967008670
flooded has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
enochazariah has quit [Quit: Client closed]
enochazariah has joined #bitcoin-core-dev
fgarau has quit [Ping timeout: 272 seconds]
TheRec has joined #bitcoin-core-dev
TheRec has quit [Changing host]
TheRec has joined #bitcoin-core-dev
Guest42 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] brunoerg opened pull request #33003: test: add option to skip large re-org test in feature_block (master...2025-07-test-featureblock-skiplargereorg) https://github.com/bitcoin/bitcoin/pull/33003
Guest42 has quit [Client Quit]
joetor5 has joined #bitcoin-core-dev
enochazariah has quit [Quit: Client closed]
enochazariah has joined #bitcoin-core-dev
SpellChecker has joined #bitcoin-core-dev
SpellChecker_ has quit [Ping timeout: 244 seconds]
eremitah has quit [Ping timeout: 272 seconds]
joetor5 has quit [Quit: joetor5]
enochazariah has quit [Quit: Client closed]
enochazariah has joined #bitcoin-core-dev
enochazariah53 has joined #bitcoin-core-dev
enochazariah53 has quit [Client Quit]
jonatack has joined #bitcoin-core-dev
Guest48 has joined #bitcoin-core-dev
Guest48 has quit [Quit: Client closed]
bugs_ has joined #bitcoin-core-dev
Cory70 has quit [Quit: Client closed]
Cory70 has joined #bitcoin-core-dev
enochazariah has quit [Remote host closed the connection]
enochazariah has joined #bitcoin-core-dev
fgarau has joined #bitcoin-core-dev
Christoph_ has quit [Quit: Christoph_]
jarthur has joined #bitcoin-core-dev
enochazariah has quit [Remote host closed the connection]
enochazariah has joined #bitcoin-core-dev
<fanquake>
#proposedmeetingtopic 29.1
Emc99 has joined #bitcoin-core-dev
Cory70 has quit [Quit: Client closed]
<glozow>
hi
Cory70 has joined #bitcoin-core-dev
<glozow>
#startmeeting
<corebot>
glozow: Meeting started at 2025-07-17T16:00+0000
<glozow>
I see 2 preproposed topics from darosior and fanquake - anything else to add / am I missing any?
<brunoerg>
hi
<glozow>
#topic Erlay WG Update (sr_gi, gleb)
eugenesiegel has joined #bitcoin-core-dev
f321x has quit [Quit: f321x]
<laanwj>
hi
<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.
<glozow>
sr_gi?
<glozow>
(nvm, I see your message now)
<sr_gi[m]1>
I've reworked the Warnet simulations to use this, which have made them way less flaky
<glozow>
#topic QML GUI WG Update (jarolrod, johnny9dev)
<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
<johnny9dev>
rebase all of my current work on top.
<glozow>
Does anybody else want to give WG updates? I skipped most of them based on attendance
<glozow>
#topic Turn -natpmp on by default (darosior)
<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
<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
<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
<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?
<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.
<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
<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
<glozow>
Seems pretty well-tested
Cory70 has quit [Quit: Client closed]
<darosior>
I agree. I think the benefits outweigh the risk now.
Cory70 has joined #bitcoin-core-dev
<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
<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
<stickies-v>
why is it "not really useful unless enabled by default"?
<darosior>
Yeah it seems to be an improvement of the feature but not a requirement for 30.
<laanwj>
if it can't find the default router, it'll default to not using it, which is the safe choice
<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.
<laanwj>
stickies-v: because the idea is that it's effortless; if it requires people to set things up, it's less useful
<laanwj>
e.g. if yu have to enable settings, it's slightly more work to forward a port yourself
enochazariah has quit [Read error: Connection reset by peer]
<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
<stickies-v>
(note: i'm not arguing against disabling it by default)
enochazariah has joined #bitcoin-core-dev
<laanwj>
okay, yes, probably
<laanwj>
that's true
<stickies-v>
s/disabling it by default/enabling it by default/
<darosior>
I don't think so. I'd even think more people know about NAT traversal than about the specific NAT hole-punching protocols
<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
<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
<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.
Naiyoma has joined #bitcoin-core-dev
<darosior>
Ok, i think i'll make a PR and we can follow-up there?
<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
<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
<laanwj>
yes, let's do that
<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
<sipa>
(phone typing, sorry for typos)
<jonatack>
hi
<laanwj>
more home users is a good thing for decentralization, anyhow. but yes, it could have unexpected effects.
<sipa>
right, obviouslu!
<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
<sipa>
right
<laanwj>
that's all i think-let's open a PR and continue discussion there
<darosior>
Yeah
<sipa>
sgtm
<glozow>
#topic 29.1 fanquake
<fanquake>
We are at ~3 months post 29.0; so about time to do a .1.
<fanquake>
What should be the final round of backports are in #32863, which are ready for review.
<fanquake>
I think darosior has a suggestion for somethign to backport
<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)
<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
<glozow>
thanks, will review
<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
<darosior>
And i'm afraid people will play shenanigans to slow down the upgrade to 30.0
entropyx has quit [Ping timeout: 276 seconds]
<glozow>
Anything else to discuss?
<glozow>
#endmeeting
<corebot>
glozow: Meeting ended at 2025-07-17T16:37+0000