16:00:01 <fjahr> #startmeeting 
16:00:01 <corebot> fjahr: Meeting started at 2026-09-10T16:00+0000
16:00:02 <corebot> fjahr: Current chairs: fjahr
16:00:04 <corebot> fjahr: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:05 <corebot> fjahr: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:06 <corebot> fjahr: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:11 <stickies-v> hi
16:00:13 <fjahr> #bitcoin -core-dev Meeting: _aj_ abubakarsadiq achow101 andrewtoth b10c brunoerg cfields danielabrozzoni darosior dergoegge 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:14 <hebasto> hi
16:00:14 <fjahr> theStack vasild willcl-ark
16:00:16 <nervana21> hi
16:00:19 <eugenesiegel> hi
16:00:20 <enochazariah> hi
16:00:21 <instagibbs> hi
16:00:22 <stringintech> hi
16:00:24 <brunoerg> hi
16:00:28 <fjahr> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:00:29 <janb84> hi
16:00:34 <andrewtoth> hi
16:00:35 <johnny9dev> Hi
16:00:35 <willcl-ark> hi
16:00:48 <lightlike> hi
16:00:51 <sedited> hi
16:00:54 <pseudoramdom> hi
16:01:02 <kanzure> hi
16:01:27 <tigerMafia> hello
16:01:37 <yancy> hi
16:01:46 <fjahr> Let's start with the WGs
16:01:50 <fjahr> #topic QA WG Update (brunoerg)
16:01:57 <brunoerg> no update this week
16:02:07 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:02:20 <johnny9dev> First chunk of the staging branch was merged in
16:02:39 <johnny9dev> Establishes the qml foundational pieces
16:02:54 <johnny9dev> hebasto helped a ton with the final review
16:03:20 <johnny9dev> I have drafts for the next two chunks. Both will setup the wallet disabled version of the gui.
16:03:33 <hebasto> post-merge review is always welcome; especially from python people
16:03:53 <cfields> hi
16:03:53 <johnny9dev> Yeah everything can be updated. Nothing has to be finalized
16:04:41 <johnny9dev> I have a rough list of all of the chunks now and the order they should go in and I will create the tracking issue to "Upgrading Gui to Qml" with it.
16:05:42 <johnny9dev> Pseudoramdom is updating the designs to make them more desktop friendly and consistent in parallel and epicleafies is taking care of transaction and activity issues
16:05:46 <johnny9dev> That's all for now
16:06:08 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:06:29 <andrewtoth> no update
16:06:33 <sipa> hi
16:06:42 <fjahr> #topic Kernel WG Update (sedited)
16:06:50 <sedited> don't have anything from my side, but stickies-v recently pushed to #34374 again and left a comment: https://github.com/bitcoin/bitcoin/pull/34374#issuecomment-5605856730
16:06:52 <corebot> https://github.com/bitcoin/bitcoin/issues/34374 | kernel: use struct-based logging and simplify logging interface by stickies-v · Pull Request #34374 · bitcoin/bitcoin · GitHub
16:06:56 <sedited> would be good to get some comments there.
16:06:59 <sedited> that's all.
16:07:33 <Murch[m]> hi
16:07:40 <theStack> hi
16:07:41 <fjahr> That's it for the WGs afaict, anything to say about the release?
16:09:12 <fanquake> I think we are looking pretty decent for branch off
16:09:16 <sedited> branch-off should be today, but there are still a few things in the milestone https://github.com/bitcoin/bitcoin/milestone/84
16:09:27 <darosior> hi
16:09:56 <fanquake> There does seem to be an outstanding thread in regards to private broadcast, which could be worth discussing now
16:10:53 <fanquake> Re what's left on the milestone, if any of those miss, they should also all be fine to backport into 32.x
16:11:22 <sedited> yes
16:11:30 <fjahr> What's the private broadcast thread?
16:12:11 <darosior> Should we do privatebroadcast now or milestone?
16:12:11 <fanquake> re private broadcast. Some privacy leaks have reported to the security team, and we'd like to facilitate a broader discussion about the threat model to know how to handle those
16:12:55 <fanquake> I don't think there's too much to discuss on the milestone, other than, everything is looking for review
16:13:03 <fanquake> (or if someone thinks something is missing)
16:14:16 <fjahr> fanquake: but is that something still relevant for the release, e.g. putting some warning in there, or is this a discussion unrelated to the release
16:14:54 <fanquake> fjahr: I think it's both
16:15:10 <sedited> my impression is the base assumption of the feature is "no worse privacy than only connecting through tor"
16:16:06 <andrewtoth> there's one issue i think we should patch
16:16:21 <andrewtoth> not sure what we are discussing here exactly though
16:17:10 <instagibbs> so for release, we could suggest remediations such as preferred configurations, or soft enforce them in releases. as an example
16:17:49 <sedited> what do you mean with preferred configurations instagibbs?
16:18:28 <andrewtoth> I'm not sure having to speak cryptically in a public conversation is helpful. Otherwise we should have a private conversation somewhere else where we can discuss everything openly.
16:18:50 <darosior> My understanding is there is more than one issue, and that it's not clear how far we want to go in patching them, and how to think about it consistently.
16:19:28 <darosior> andrewtoth: i think we can discuss openly what privacy guarantees we want to provide users. Then the specific instances in which they are breached can be kept momentarily private like we do for security breaches.
16:19:58 <fanquake> I think a situation where we need to ship a feature with a caveat of *maybe don't use it unless you configure it a certain way*, but we don't make that the default, is not great
16:20:07 <instagibbs> sedited f.e. we could encourage peoeple who want higher assurance that the run onlynet=onion, or similar. Or maybe this is again just pure communication about privacy model
16:20:34 <lightlike> yes, we could mention that private broadcast is still somewhat new/experimental and recommend to combine it with -onlynet=onion and -listen=0 if privacy is really needed instead of fully trusting it.
16:20:56 <instagibbs> ^ less inbound influence, that sort of thing yes
16:21:15 <sipa> (I haven't followed the issues) is there much of a point to privatebroadcast if you're in -onlynet=onion -listen=0 ?
16:21:45 <instagibbs> I think the idea was logical OR?
16:21:48 <sedited> agree with sipa, there seems to be no point to the feature if that is the case.
16:22:24 <lightlike> sipa: correlating multiple connections originating from a node - any random outbound peer could do that.
16:22:31 <sipa> There is a small advantage still, namely that the receiver cannot correlate it with other traffic from you.
16:22:34 <sipa> Right.
16:22:56 <lightlike> *multiple transactions, not connections
16:24:41 <sedited> I think this should be a binary choice. Either it works as advertised, or it doesn't and should be removed.
16:25:01 <instagibbs> "as advertised" doing all the work
16:25:15 <andrewtoth> so what are we advertising?
16:25:23 <darosior> Yeah exactly, i agree with sedited but what guarantee are we aiming to provide
16:25:34 <fjahr> Depending on how easy to exploit the leak is, maybe documentation is not enough and we should enforce the settings until we have had the broader discussion. We should assume at least some users really need serious privacy if they use it and it seems risky no only use documentation.
16:26:20 <andrewtoth> either we are talking about the guarantees we want to provide, or we are talking about some mitigation for something we can't disclose
16:26:36 <sipa> The 31.0 release notes make some promises.
16:26:56 <darosior> Are shooting for "If you are not a reachable node, operating only on Tor, then we guarantee the transactions you broadcast won't be easily correlated with each other"?
16:26:58 <instagibbs> If our privacy model is "honest but curious", then AFAIK we cover that. It's also about user expectations
16:27:16 <instagibbs> but that;s hard to to communicate, and weaker
16:27:38 <instagibbs> "what's honest but curious": they follow protocol, but write everything down, say
16:27:45 <fanquake> The claims in https://bitcoincore.org/en/releases/31.0/ are "Their IP address (and thus geolocation) is never known to the recipients." & "If the originator sends two otherwise unrelated transactions, they will not be linkable. This is because a separate connection is used for broadcasting each transaction. "
16:27:51 <darosior> instagibbs: so, passive observer?
16:27:54 <instagibbs> vs active probing, protcool violations
16:27:54 <sedited> yeah, that seems very clear.
16:28:06 <instagibbs> darosior they follow the stated protocol
16:28:14 <instagibbs> whatever that means
16:28:26 <instagibbs> the prior issue we had and fixed violated this
16:28:27 <sipa> There isn't even a well-defined "honest" behavior for nodes.
16:28:39 <instagibbs> sipa handwaving here
16:29:00 <sedited> if we can't guarantee what's in those release notes, then we should not ship the feature imo.
16:29:19 <darosior> Making a difference between passive and active attackers here make sense, but i'm concerned it would be hard to translate into an actionable information for users, and end up being a footgun.
16:29:57 <sipa> Right, but "honest but curious" is trivially false, if every behavior is "honest". That's a term that's used in cryptographic protocol with a well-defined prescription of how honest parties operate. Bitcoin doesn't have any of those.
16:29:59 <instagibbs> fanquake ok that note is wrong, two txs can be linked at the blockchain layer even with perfect impl
16:30:18 <instagibbs> "not be linkable at the networking layer" maybe
16:30:35 <andrewtoth> instagibbs "otherwise unrelated" though
16:30:48 <andrewtoth> maybe that can be better defined
16:30:52 <instagibbs> andrewtoth well, theyre all related :D but yes
16:31:36 <instagibbs> sipa ok, then that. dont worry about my misuse of labels too much
16:32:10 <sipa> instagibbs: no, i literally don't understand what you mean
16:33:01 <sipa> like you seem to have an implicit understanding of what "an honest node" means, but i think there is no such thing, and i don't know what it ought to entail
16:33:25 <darosior> What threshold are we aiming for to release this feature? That it prevents linkage at the network layer against a passive observer? Against an active one if you are not reachable? Against an active one if you are not reachable AND Tor-only? Against an active one no matter one?
16:33:29 <instagibbs> maybe the answer is "no we have no common definitions of what we're promising"
16:35:03 <andrewtoth> ideally the strongest, but it's hard to say whether we can do it or not. Some issues preventing that can be patched easily, some I've seen are very theoretical and don't seem plausible.
16:35:06 <b10c> hi
16:36:05 <instagibbs> let's save the risk estimation for the security team, please
16:36:13 <instagibbs> at least for now
16:36:30 <andrewtoth> well then we want to keep the guarantees from v31 release notes?
16:37:30 <fjahr> We need to have some clarifying information though, the feature is called privatebroadcast so people will expect something just based on that
16:37:56 <andrewtoth> yeah, this conversation is too difficult if everything is not on the table
16:38:11 <dzxzg> +1
16:38:20 <darosior> It's hard for me to see how we could give these guarantees completely as long as we have the mechanism embedded in net_processing, so plausibility may need to be discussed as part of the goal here. Are we happy to ship this feature if we give "reasonable" guarantees, i.e. kill the really low hanging fruits, on a "it's better than nothing" basis?
16:38:51 <darosior> fjahr: +1 for expectations
16:39:31 <sipa> Maybe this needs a discussion at coredev, and a focus right now about what we can reasonable address by documentation clarification for 32?
16:39:38 <instagibbs> ^ this
16:39:56 <tigerMafia> fjahr: +1
16:40:25 <andrewtoth> how can we focus on what we can reasonably address if we can't discuss the issues?
16:42:01 <darosior> Yeah i was really still on the binary question of what threshold are we setting for ourselves (which necessarily entail not shipping it at all until it meets that threshold, instead of trying to address it with documentation).
16:42:09 <dzxzg> If the security model has changed substantially since when the feature was shipped it should be disabled or renamed, but I do think something should ship which is better than the default
16:42:47 <darosior> My favorite shed for the rename is -cloakedbroadcast /s
16:43:57 <andrewtoth> i don't think we should disable it, it is better than the default way to broadcast.
16:43:59 <darosior> (But i do think rename makes more sense than documenting a feature called "private X" with caveats "actually not private in scenarii x, y and z")
16:44:12 <instagibbs> dzxzg issue is I'm not sure we agreed ahead of time
16:44:40 <sedited> I'm confused, what's not clear about the release note there?
16:44:53 <instagibbs> I dont read the docs
16:45:00 <instagibbs> *ducks*
16:45:03 <sedited> :D
16:45:21 <sipa> instagibbs: well, you or your agent
16:45:27 <darosior> sedited: fair
16:45:57 <instagibbs> the docs seem to match my expectation of the feature in my head so maybe less confusion than im letting on
16:48:59 <yancy> I think the wording "never known" might give a false sense of security.
16:49:40 <darosior> Ok since i don't think the status quo is desirable, i suggest we rename the feature for the upcoming release, with a name that does not give as much expectation as "private" broadcast, and make weaker claims in our release notes than we did for 31. This way we keep the option for now because it's better than the other broadcast, but also don't risk
16:49:40 <darosior> users depending on something we cannot guarantee.
16:49:58 <instagibbs> ah the easy part, naming things
16:50:10 <fjahr> -betterthanthedefaultbroadcast it is
16:50:28 <sliv3r__> -broadcast++
16:50:51 <tigerMafia> yancy: yes! given the current state of the discussion, it's VERY bold
16:50:58 <darosior> I don't think it's a great situation, but i don't have a better idea for 32 literally on the day of branch off.
16:51:05 <andrewtoth> a release not warning is not enough?
16:51:11 <andrewtoth> *note
16:51:21 <eugenesiegel> -notsoprivatebroadcast
16:51:31 <sedited> this will have to be backported anway, so we'll have a few weeks to discuss.
16:51:44 <lightlike> and when we fixed the known issues, do we rename it back to "private broadcast"?
16:52:15 <darosior> lightlike: -evenbetterthandefaultbroadcast
16:52:16 <andrewtoth> lightlike +1 - release note warning is better
16:53:23 <darosior> I don't think a release note is nearly enough to compensate for the potential sense of security providing a feature called "private X" may give to users.
16:53:58 <tigerMafia> how's "-veilbroadcast" since it's partial in privacy
16:54:04 <instagibbs> release note warning should happen regardless
16:54:07 <darosior> Anyways, i don't have much to add on this topic.
16:55:19 <fjahr> The meeting is coming to a close in 5min, feel free to continue discussing renaming vs. release notes, but is there anything else anyone wanted to discuss/announce in the meeting?
16:56:29 <fjahr> I think renaming should be to some name that doesn't make any promises, like -oneshottorbroadcast then we don't have issues like this with naming
16:56:46 <fjahr> (if people want a renaming)
16:57:39 <dzxzg> no strong feeling about what the name should be, but the point of renaming in my mind is less about the promises the name makes and more to catch people that haven't read release notes or new documentation and go on using private broadcast with the wrong expectations
16:58:06 <Murch[m]> Isn’t the point that the transaction appears to come from a node that isn’t the sender?
16:58:23 <Murch[m]> So, maybe “teleportbroadcast” or “strawmanbroadcast” or smth?
16:58:50 <Murch[m]> surrogatebroadcast? :p
16:59:10 <instagibbs> temudandelion
16:59:17 <Murch[m]> heh
16:59:21 <instagibbs> im JOKING
16:59:40 <fjahr> Murch: sounds still fine, as long as it's more descriptive of the mechanism rather than making promises of an end result
16:59:44 <yancy> shielded-broadcast is my bikeshed color
16:59:58 <fjahr> sipa about to suggest -minibroadcast
17:00:08 <fjahr> Ok, let's end the meeting with this :D
17:00:16 <fjahr> #endmeeting