16:00:05 <stickies-v> #startmeeting 
16:00:05 <corebot> stickies-v: Meeting started at 2026-10-22T16:00+0000
16:00:06 <corebot> stickies-v: Current chairs: stickies-v
16:00:07 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:08 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:09 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:10 <darosior> hi
16:00:12 <achow101> hi
16:00:13 <willcl-ark> hi
16:00:15 <andrewtoth_> hi
16:00:15 <stickies-v> #bitcoin -core-dev Meeting: _aj_ abubakarsadiq achow101 andrewtoth b10c brunoerg cfields danielabrozzoni darosior dzxzg eugenesiegel fanquake fjahr furszy hebasto hodlinator instagibbs janb84 jarolrod johnny9dev jonatack josie jurraca kanzure kevkevin laanwj lightlike l0rinc maflcko marcofleon maxedw Murch pinheadmz provoostenator pseudoramdom ryanofsky sdaftuar sedited sipa sliv3r__ sr_gi stickies-v stringintech
16:00:15 <stickies-v> theStack vasild willcl-ark
16:00:18 <instagibbs> hi
16:00:22 <hebasto> hi
16:00:25 <eugenesiegel> hi
16:00:25 <marcofleon> hi
16:00:25 <johnny9dev> Hi
16:00:28 <achow101> would like for my topic to be first, so I can go to sleep
16:00:35 <brunoerg> Hi
16:00:55 <stickies-v> we have one pre-proposed meeting topic for this week, any others to add?
16:00:58 <enochazariah> hi
16:01:10 <darosior> 9AM bedtime?
16:01:22 <tigerMafia> hello world
16:01:23 <instagibbs> stickies-v I'd like to speak briefly about #36608 later
16:01:24 <achow101> i'm still in <redacted>, it's 1 am
16:01:25 <corebot> https://github.com/bitcoin/bitcoin/issues/36608 | Reimplement private broadcast as node state-less jobs + package relay support by instagibbs · Pull Request #36608 · bitcoin/bitcoin · GitHub
16:01:26 <stickies-v> achow101: sure, i'll take that one first after the WGs if that's okay
16:01:39 <yancy> hi
16:01:45 <achow101> stickies-v: ok
16:01:46 <Murch[m]> hi
16:01:47 <stickies-v> instagibbs: will add it
16:01:51 <yancy> s/lying/laying
16:02:08 <kanzure_> hi
16:02:11 <stickies-v> #topic Fuzzing WG Update (eugenesiegel, marcofleon)
16:03:15 <marcofleon> no update from me
16:03:29 <eugenesiegel> currently just working on getting bedrock into shape so we can run fuzzamoto with it. some faults I added found some really minor database consistency issues
16:04:19 <stickies-v> #topic QML GUI WG Update (johnny9dev)
16:04:20 <eugenesiegel> like e.g. a node having a power loss at a super specific point during -reindex prevents the node from starting up again. should things like that be fixed?
16:04:25 <johnny9dev> We got a lot of good feedback last week and we've started working through that.
16:04:33 <stickies-v> oops sorry
16:04:33 <stickies-v> #topic Fuzzing WG Update (eugenesiegel, marcofleon)
16:04:42 <eugenesiegel> woops, too slow
16:06:07 <stickies-v> eugenesiegel: if it's a loud failure, i wouldn't personally consider that worth spending a lot of energy or complexity on
16:06:34 <yancy> eugensiegel: might it also be OS disk corruption?
16:06:34 <stickies-v> silent consensus failures/money losing behaviour is a different thing of course
16:07:38 <eugenesiegel> I don't think it's a disk corruption issue, just a things not being persisted in the proper order/way. It wasn't clear to me what guarantees the codebase should have against all possible scenarios like that where there's no critical failure like consensus failure / money loss
16:07:40 <brunoerg> perhaps it depends on how complex the fix would be?
16:08:27 <eugenesiegel> I think the fixes are pretty small. I don't think it's likely that anybody will run into these issues though
16:09:19 <eugenesiegel> that's it from me though
16:10:30 <stickies-v> #topic QML GUI WG Update (johnny9dev)
16:10:35 <johnny9dev> As I mentioned were working on the feedback from last week.
16:10:57 <johnny9dev> We've got a pr to clarify storage choices during onboarding
16:11:28 <johnny9dev> Priority is getting the staging branch ready
16:12:37 <johnny9dev> I am increasingly interested in making a pruned wallet setup working and have started looking into the txindex and compact block filters
16:13:16 <darosior> You mean pruned rescans?
16:13:16 <sipa> hi
16:13:27 <johnny9dev> Yeah pruned rescans
16:13:44 <johnny9dev> Block retrieval
16:14:13 <johnny9dev> Anyway I think that will become a high priority for the Qml project once the staging branch is settled
16:14:29 <johnny9dev> That's all for now.
16:14:37 <darosior> eugenesiegel: worth at least opening an issue for those IMO, may be a symptom of a bug that could open up more serious inconsistencies down the road. As far as i know we should always be able to recover from a crash?
16:15:34 <eugenesiegel> darosior: (y)
16:15:42 <Murch[m]> We chatted a bit about potential release timeline for the new GUI recently. There was an argument that such a big change should be merged very early in a release cycle, right after branch-off, and that it therefore should only be considered for v34. However, I’d like to submit that it sounds like the new GUI has significantly better testing infrastructure, way more eyes, and it feels somewhat uncomfortable to release with the old GUI in
16:15:42 <Murch[m]> the time of daily RCEs when hardly anyone is actually looking at the old GUI.
16:16:03 <Murch[m]> Maybe we should talk more about whether we should try to get the new GUI into v33.
16:17:12 <hebasto> it seems premature until the staging branch is ready
16:17:41 <johnny9dev> My current view on it is that we'll have the PR by the end of the year. Likely end of November or early December if I had to guess right now.
16:18:09 <stickies-v> i'm not sure merging a huge amount of new code is necessarily safer RCE/vulnerability wise, so I don't think we should feel time pressure because of that
16:18:12 <Murch[m]> Sure, let’s revisit when the staging branch is available
16:18:32 <hebasto> ^ agree
16:20:02 <stickies-v> #topic QA WG Update (brunoerg)
16:20:19 <brunoerg> no updates this week
16:20:30 <cfields> hi
16:20:50 <stickies-v> alright, that's all for the WG updates then
16:20:56 <stickies-v> #topic another windows code signer (achow101)
16:21:07 <achow101> right now windows code signing is done by only me, which is a single point of failure that i would prefer we did not have. if anyone is interested in being a code signer, shoot me a message
16:21:29 <achow101> needs to be someone who currently builds, or will commmit to building, all releases and release candidates shortly after tagging
16:21:39 <achow101> that's all
16:23:13 <stickies-v> #topic Reimplement private broadcast as node state-less jobs + package relay support (#36608) (instagibbs)
16:23:15 <corebot> https://github.com/bitcoin/bitcoin/issues/36608 | Reimplement private broadcast as node state-less jobs + package relay support by instagibbs · Pull Request #36608 · bitcoin/bitcoin · GitHub
16:23:20 <instagibbs> Hi, I'd like to share something I've been working on for the last few months.
16:23:20 <instagibbs> I've been working on a node state-less variant of private broadcast, and I believe
16:23:20 <instagibbs> it's mature enough to be considered for replacement for v33 release. It makes
16:23:20 <instagibbs> some opinionated decisions in order to make reasoning about the afforded privacy easier.
16:23:20 <instagibbs> It's meant to be a feature swap out, still using the same `sendrawtransaction` path,
16:23:20 <instagibbs> and at the end has 1p1c package relay support tacked on for good measure. Also
16:23:21 <instagibbs> includes a stand-alone tool that is a thin wrapper around the same job.
16:23:27 <instagibbs> sorry for breaks
16:23:37 <instagibbs> A bit of sticker shock but: Roughly +4,600 net in logic loc, and *all* outside of consensus critical
16:23:37 <instagibbs> code (all in-master net_processing stuff for private broadcast gone), and the rest is tests and then documentation
16:23:49 <instagibbs> What I'm looking for in the short-term:
16:23:49 <instagibbs> 1. High level spec discussions / concept and approach (n)ACKs, and *a general project buy-in that we want this to happen by v33*. Now is the time to fix it fundamentally.
16:23:49 <instagibbs> 2. Do we care about an individual tool variant, which is currently included? Could be folded into another tool like bitcoin-util, or simply removed. The underlying architecture remains, whatever we choose, but could save some boilerplate and move-only commits if removed.
16:23:49 <instagibbs> 3. Should this be 2 PRs: one PR to swap everything out, and then one follow-up PR for package relay support? More? less?
16:23:54 <instagibbs> that's all, thanks
16:25:33 <andrewtoth_> I haven't looked at this in depth yet, but I'm not sure a 17k line PR is realistic to get in for v33?
16:26:07 <andrewtoth_> I left some conceptual feedback on the previous branch. It doesn't seem like any of my concerns or suggestions were addressed?
16:26:21 <instagibbs> I responded to all your comments, AFAIK
16:26:31 <cfields> instagibbs: I think that has a lot of overlap with my multi-process p2p work which may be worth reviving and teaming up on. I'll take a look and bug you out-of-band.
16:26:56 <instagibbs> and to be clear, it's ~4.6k loc net of logic, rest is tests. I can delete tests but I think it should be motivated
16:27:11 <stickies-v> yeah i think this is a big lift for a single feature, but if it goes hand in hand with a better architecture, that would be nice
16:27:41 <instagibbs> right, maybe it's two releases, but I don't think it has to be, it's removal of risk imo
16:27:49 <darosior> I agree with the approach: we should fix the node state leaks structurally, and then potentially consider carving out some exceptions if necessary to improve UX, instead of the opposite
16:28:30 <instagibbs> https://github.com/instagibbs/bitcoin/pull/7 this thread had a little back and forth which andrewtoth_ alluded to, may be informative
16:29:05 <andrewtoth_> Can we better quantify the risks this is addressing? There were several fixes for private broadcast in v32. What are the remaining gaps that we are doing this work for?
16:29:28 <instagibbs> I'm not going to list them all, and I think missing hte point
16:30:10 <instagibbs> The risks is sharing node state, which seeps out in dozens of ways
16:30:16 <darosior> We can never guarantee perfect privacy or anonymity, but if the point of private broadcast is to provide *any* limited guarantee in adversarial conditions, separating from the node's state is a requirement. If the point isn't to provide such limited guarantees in adversarial conditions, i don't know what we are doing.
16:30:44 <instagibbs> cfields cool let's chat
16:31:08 <andrewtoth_> For asking reviewers to review this work it would be good to be more forthcoming on the benefits of the work. We have private broadcast marked experimental now, and we have softened the guarantees we make about it. What are the remaining gaps in light of that?
16:32:02 <darosior> The remaining gap is that there is little point in a feature that protects a user's privacy if nobody cares to attack them in the first place
16:32:18 <andrewtoth_> linking lion is attacking all users
16:32:53 <darosior> Sure, and?
16:33:02 <instagibbs> I'd say the most interesting thing to debate about a design is the addrman-less design, since addrman is attacker influenced quite heavily, and there's tradeoffs in that direction
16:33:08 <andrewtoth_> using private broadcast protects user's privacy against linking lion today
16:33:39 <instagibbs> but certainly not limited to that
16:33:48 <darosior> This is akin to saying linking lion isn't using bip324 connections today, so let's switch to using exclusively that, and call it "private" even though it doesn't offer any privacy
16:34:18 <andrewtoth_> no i don't think that's a fair comparison
16:34:33 <instagibbs> We can do better, let's do better.
16:35:10 <andrewtoth_> default broadcast trivially exposes the transaction origin, even with bip324.
16:35:42 <darosior> Current private broadcast can expose it too, if someone cares enough to attack
16:36:08 <instagibbs> Ok, I don't want to hold people here, we can continue debating offline
16:36:12 <andrewtoth_> i'm not sure it's that trivial darosior
16:36:51 <darosior> I don't say it's exactly trivial, but i also don't think it's reasonable for a project like ours to be offering feature branded as privacy that don't hold up to a certain bar
16:37:21 <darosior> Regarding your questions, instagibbs
16:38:20 <darosior> For 2) i don't see why we'd need a new tool. bitcoin-util seems fine for this. A separate tool seems like a minor cost for a potentially useful feature (broadcast without having to fire up node), and is also useful as a canary against reintroducing state
16:39:09 <instagibbs> I started with the tool, to make sure I wasn't re-adding node state to jobs, then took that library and reused it inside the node.
16:39:27 <instagibbs> so kind of lines up
16:39:29 <darosior> For 3) i think package relay can go in a followup as an improvement, but i don't think the swap out should be broken down, to make sure we don't end up with two implementations of the same feature in master
16:40:02 <darosior> No strong opinion though. Thanks for working on this
16:42:03 <stickies-v> agreed with darosior on 3)
16:42:18 <stickies-v> anything else to discuss?
16:42:44 <fanquake> v32.0 has been tagged
16:43:05 <fanquake> The updates to the security policy have been merged: https://github.com/bitcoin-core/bitcoincore.org/pull/1281
16:43:28 <fanquake> PR to enrol core in the anthropic oss scanner: https://github.com/anthropics/oss-scanner/pull/1018
16:46:10 <stickies-v> ty for the updates fanquake. looks like that's all for today
16:46:17 <stickies-v> big meeting, thanks everyone for participating!
16:46:24 <stickies-v> #endmeeting