BlueMattMtrxBot has quit [Ping timeout: 262 seconds]
stratospher[m] has quit [Ping timeout: 262 seconds]
b10c[m] has quit [Ping timeout: 263 seconds]
BlueMatt[m] has quit [Ping timeout: 263 seconds]
upekkha has quit []
upekkha has joined #bitcoin-core-dev
Murch[m] has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
Sjors[m] has joined #bitcoin-core-dev
stratospher[m] has joined #bitcoin-core-dev
BlueMattMtrxBot has joined #bitcoin-core-dev
b10c has joined #bitcoin-core-dev
BlueMatt[m] has joined #bitcoin-core-dev
b10c[m] has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
WizJin has joined #bitcoin-core-dev
adil has joined #bitcoin-core-dev
adil has quit [Client Quit]
cotsuka has quit [Read error: Connection reset by peer]
dviola has quit [Ping timeout: 254 seconds]
diego has joined #bitcoin-core-dev
cotsuka has joined #bitcoin-core-dev
ozdeadman has quit [Ping timeout: 262 seconds]
ozdeadman has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
PaperSword has quit [Quit: PaperSword]
PaperSword has joined #bitcoin-core-dev
adil has joined #bitcoin-core-dev
adil has quit [Client Quit]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] yuvicc opened pull request #36214: test: cover cluster limits during reorgs (master...2026-7-add_reorg_test_cluster_mempoool) https://github.com/bitcoin/bitcoin/pull/36214
enochazariah has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 260 seconds]
l0rinc has joined #bitcoin-core-dev
enochazariah has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 260 seconds]
Earnestly has quit [Ping timeout: 260 seconds]
Earnestly has joined #bitcoin-core-dev
enochazariah has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
l0rinc has quit [Read error: Connection reset by peer]
l0rinc has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 262 seconds]
enochazariah has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 243 seconds]
enochazariah has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
tegila_ has joined #bitcoin-core-dev
cotsuka has joined #bitcoin-core-dev
tegila has quit [Ping timeout: 250 seconds]
enochazariah has quit [Ping timeout: 261 seconds]
l0rinc has quit [Quit: l0rinc]
l0rinc has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
enochazariah has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 265 seconds]
enochazariah has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 265 seconds]
enochazariah has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
enochazariah has quit [Read error: Connection reset by peer]
l0rinc has quit [Quit: l0rinc]
cotsuka has quit [Read error: Connection reset by peer]
jon_atack has joined #bitcoin-core-dev
cotsuka has joined #bitcoin-core-dev
enochazariah has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 255 seconds]
smartin2 has joined #bitcoin-core-dev
smartin has quit [Ping timeout: 258 seconds]
smartin2 is now known as smartin
enochazariah has quit [Read error: Connection reset by peer]
enochazariah has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hodlinator opened pull request #36215: asmap: Make version match externally computed hashes (master...2026/09/asmap_ver_s256) https://github.com/bitcoin/bitcoin/pull/36215
<bitcoin-git>
bitcoin/master 9c77483 fanquake: build: avoid pipe2 on Darwin (for now)
<bitcoin-git>
bitcoin/master 51b540c merge-script: Merge bitcoin/bitcoin#36218: build: avoid `pipe2` on Darwin (for now)
<bitcoin-git>
[bitcoin] fanquake merged pull request #36218: build: avoid `pipe2` on Darwin (for now) (master...macos_avoid_pipe2_atm) https://github.com/bitcoin/bitcoin/pull/36218
<hebasto>
post-merge review is always welcome; especially from python people
<cfields>
hi
<johnny9dev>
Yeah everything can be updated. Nothing has to be finalized
l0rinc has quit [Ping timeout: 248 seconds]
<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.
<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
<johnny9dev>
That's all for now
<fjahr>
#topic Benchmarking WG Update (l0rinc, andrewtoth)
pseudoramdom has quit [Remote host closed the connection]
<fanquake>
There does seem to be an outstanding thread in regards to private broadcast, which could be worth discussing now
<fanquake>
Re what's left on the milestone, if any of those miss, they should also all be fine to backport into 32.x
<sedited>
yes
<fjahr>
What's the private broadcast thread?
<darosior>
Should we do privatebroadcast now or milestone?
<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
<fanquake>
I don't think there's too much to discuss on the milestone, other than, everything is looking for review
<fanquake>
(or if someone thinks something is missing)
<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
<fanquake>
fjahr: I think it's both
<sedited>
my impression is the base assumption of the feature is "no worse privacy than only connecting through tor"
cotsuka has quit [Read error: Connection reset by peer]
<andrewtoth>
there's one issue i think we should patch
l0rinc has joined #bitcoin-core-dev
<andrewtoth>
not sure what we are discussing here exactly though
<instagibbs>
so for release, we could suggest remediations such as preferred configurations, or soft enforce them in releases. as an example
<sedited>
what do you mean with preferred configurations instagibbs?
<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.
cotsuka has joined #bitcoin-core-dev
<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.
<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.
<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
<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
<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.
<instagibbs>
^ less inbound influence, that sort of thing yes
<sipa>
(I haven't followed the issues) is there much of a point to privatebroadcast if you're in -onlynet=onion -listen=0 ?
l0rinc has quit [Quit: l0rinc]
<instagibbs>
I think the idea was logical OR?
<sedited>
agree with sipa, there seems to be no point to the feature if that is the case.
svanstaa has joined #bitcoin-core-dev
<lightlike>
sipa: correlating multiple connections originating from a node - any random outbound peer could do that.
<sipa>
There is a small advantage still, namely that the receiver cannot correlate it with other traffic from you.
<sipa>
Right.
<lightlike>
*multiple transactions, not connections
<sedited>
I think this should be a binary choice. Either it works as advertised, or it doesn't and should be removed.
<instagibbs>
"as advertised" doing all the work
<andrewtoth>
so what are we advertising?
<darosior>
Yeah exactly, i agree with sedited but what guarantee are we aiming to provide
<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.
<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
<sipa>
The 31.0 release notes make some promises.
<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"?
<instagibbs>
If our privacy model is "honest but curious", then AFAIK we cover that. It's also about user expectations
<instagibbs>
but that;s hard to to communicate, and weaker
<instagibbs>
"what's honest but curious": they follow protocol, but write everything down, say
<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. "
<darosior>
instagibbs: so, passive observer?
<instagibbs>
vs active probing, protcool violations
<sedited>
yeah, that seems very clear.
<instagibbs>
darosior they follow the stated protocol
<instagibbs>
whatever that means
<instagibbs>
the prior issue we had and fixed violated this
<sipa>
There isn't even a well-defined "honest" behavior for nodes.
<instagibbs>
sipa handwaving here
<sedited>
if we can't guarantee what's in those release notes, then we should not ship the feature imo.
<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.
<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.
<instagibbs>
fanquake ok that note is wrong, two txs can be linked at the blockchain layer even with perfect impl
<instagibbs>
"not be linkable at the networking layer" maybe
<andrewtoth>
instagibbs "otherwise unrelated" though
<andrewtoth>
maybe that can be better defined
<instagibbs>
andrewtoth well, theyre all related :D but yes
<instagibbs>
sipa ok, then that. dont worry about my misuse of labels too much
vasild has quit [Remote host closed the connection]
<sipa>
instagibbs: no, i literally don't understand what you mean
vasild has joined #bitcoin-core-dev
<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
<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?
<instagibbs>
maybe the answer is "no we have no common definitions of what we're promising"
<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.
<b10c>
hi
<instagibbs>
let's save the risk estimation for the security team, please
<instagibbs>
at least for now
<andrewtoth>
well then we want to keep the guarantees from v31 release notes?
<fjahr>
We need to have some clarifying information though, the feature is called privatebroadcast so people will expect something just based on that
<andrewtoth>
yeah, this conversation is too difficult if everything is not on the table
<dzxzg>
+1
<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?
<darosior>
fjahr: +1 for expectations
<sipa>
Maybe this needs a discussion at coredev, and a focus right now about what we can reasonable address by documentation clarification for 32?
<instagibbs>
^ this
<tigerMafia>
fjahr: +1
<andrewtoth>
how can we focus on what we can reasonably address if we can't discuss the issues?
<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).
<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
<darosior>
My favorite shed for the rename is -cloakedbroadcast /s
pzafonte has quit [Ping timeout: 250 seconds]
<andrewtoth>
i don't think we should disable it, it is better than the default way to broadcast.
<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")
<instagibbs>
dzxzg issue is I'm not sure we agreed ahead of time
<sedited>
I'm confused, what's not clear about the release note there?
<instagibbs>
I dont read the docs
<instagibbs>
*ducks*
<sedited>
:D
<sipa>
instagibbs: well, you or your agent
<darosior>
sedited: fair
<instagibbs>
the docs seem to match my expectation of the feature in my head so maybe less confusion than im letting on
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
<yancy>
I think the wording "never known" might give a false sense of security.
<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
<darosior>
users depending on something we cannot guarantee.
<andrewtoth>
lightlike +1 - release note warning is better
<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.
<tigerMafia>
how's "-veilbroadcast" since it's partial in privacy
<instagibbs>
release note warning should happen regardless
<darosior>
Anyways, i don't have much to add on this topic.
<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?
<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
<fjahr>
(if people want a renaming)
<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
enochazariah has quit [Ping timeout: 271 seconds]
<Murch[m]>
Isn’t the point that the transaction appears to come from a node that isn’t the sender?
<Murch[m]>
So, maybe “teleportbroadcast” or “strawmanbroadcast” or smth?
<Murch[m]>
surrogatebroadcast? :p
<instagibbs>
temudandelion
<Murch[m]>
heh
<instagibbs>
im JOKING
<fjahr>
Murch: sounds still fine, as long as it's more descriptive of the mechanism rather than making promises of an end result
<yancy>
shielded-broadcast is my bikeshed color
<fjahr>
sipa about to suggest -minibroadcast
<fjahr>
Ok, let's end the meeting with this :D
<fjahr>
#endmeeting
<corebot>
fjahr: Meeting ended at 2026-09-10T17:00+0000
ViniciusCestarii has quit [Ping timeout: 258 seconds]
enochazariah has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 266 seconds]
enochazariah has joined #bitcoin-core-dev
nervana21 has quit [Quit: WeeChat 4.10.0]
<andrewtoth>
based on my understanding of the issues, what about if instead of a doc/name change, in v32 (and backport to v31), we tie -privatebroadcast=1 to require -listen=0?
b10c has quit [Ping timeout: 241 seconds]
bitcoin-git has quit [Ping timeout: 250 seconds]
Murch[m] has quit [Ping timeout: 250 seconds]
BlueMatt[m] has quit [Ping timeout: 240 seconds]
<andrewtoth>
so you won't be able to startup without separately adding -listen=0
BlueMattMtrxBot has quit [Ping timeout: 243 seconds]
Sjors[m] has quit [Ping timeout: 264 seconds]
<andrewtoth>
that seems to mitigate any plausible issues
stratospher[m] has quit [Ping timeout: 263 seconds]
b10c[m] has quit [Ping timeout: 271 seconds]
<andrewtoth>
we can work on removing that restriction afterwards
jonatack has quit [Ping timeout: 250 seconds]
<instagibbs>
we kinda have to do a doc change regardless
bitcoin-git has joined #bitcoin-core-dev
Murch[m] has joined #bitcoin-core-dev
b10c has joined #bitcoin-core-dev
BlueMatt[m] has joined #bitcoin-core-dev
b10c[m] has joined #bitcoin-core-dev
Sjors[m] has joined #bitcoin-core-dev
stratospher[m] has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
w0xlt has quit [Ping timeout: 260 seconds]
BlueMattMtrxBot has joined #bitcoin-core-dev
<andrewtoth>
well rather than the name change
cotsuka has joined #bitcoin-core-dev
Murch[m] has quit [Changing host]
Murch[m] has joined #bitcoin-core-dev
<andrewtoth>
i see this was discussed combined with onlynet=onion. I think tying it to onlynet=onion would be too much of a restriction. But I'm not sure that's necessary.
<Murch[m]>
wdym? I think your sentence is missing a word
<andrewtoth>
instead of changing the name, ship with required -listen=0?
enochazariah has quit [Ping timeout: 252 seconds]
<Murch[m]>
I meant to reply to your first sentence, sorry, it went out right when you elaborated
enochazariah has joined #bitcoin-core-dev
<vasild>
I just read the conversation above wrt privatebroadcast issues, renaming it, disabling it or whatever. Hmm, what are you talking about? What are the "issues" with it that would warrant that? Looks like I am the only one who has no clue what's going on.
eugenesiegel has quit [Quit: Client closed]
<sedited>
vasild the discussion was about how the security group should understand the guarantees the feature should provide, not any particular issues about it.
<andrewtoth>
well it was definitely a bit of both
<vasild>
"not any particular issues about it" -- What's with the -onlynet=onion and -listen=0 options?
<sedited>
I don't think there is anything with them.
w0xlt has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
sorukumar has quit [Quit: Client closed]
dzxzg2 has joined #bitcoin-core-dev
enochazariah has quit [Ping timeout: 251 seconds]
naiyoma has quit [Remote host closed the connection]
andrewtoth has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
navidr has quit [Quit: Connection closed for inactivity]
cotsuka has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
jerryf has quit [Remote host closed the connection]
l0rinc has joined #bitcoin-core-dev
jerryf has joined #bitcoin-core-dev
jerryf has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
enochazariah__ has quit [Quit: Connection closed for inactivity]
l0rinc has quit [Quit: l0rinc]
cotsuka has quit [Read error: Connection reset by peer]
jerryf has quit [Remote host closed the connection]
cotsuka has joined #bitcoin-core-dev
jerryf has joined #bitcoin-core-dev
durandal_ has quit [Remote host closed the connection]
memset has quit [Remote host closed the connection]
durandal_ has joined #bitcoin-core-dev
memset has joined #bitcoin-core-dev
smartin has quit [Quit: smartin]
jonatack has quit [Ping timeout: 253 seconds]
dodo has quit [Remote host closed the connection]
dodo has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
l0rinc has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
cotsuka has quit [Read error: Connection reset by peer]
cotsuka has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
<bitcoin-git>
[bitcoin] nebula-21 opened pull request #36224: test: Add test coverage for `PartiallySignedTransaction::Merge()` (master...merge-psbt-coverage) https://github.com/bitcoin/bitcoin/pull/36224
cotsuka has quit [Read error: Connection reset by peer]