Hello ๐ folks, Iโm Kevkevin. Iโm an open-source developer and reporter for Insider Edition. Last week, I reviewed several pull requests from the Bitcoin Core repo.
In the Bitcoin Core 31.0 release notes, the private broadcast feature promised that your IP would never be known to the recipients and that unrelated transactions would not be linked. In the weekly IRC meeting, there was discussion on whether Bitcoin Core can still back that.
Fankquake mentioned that privacy leaks had been reported to the security team, and they wanted broader threat model discussion before releasing v32.0. There was also discussion on renaming the flag; here are some of the options. (-cloakedbroadcast, -oneshottorbroadcast, -notsoprivatebroadcast, -temudandelion)Branch-off for v32.0 was supposed to be yesterday. But there is still no 32.x branch and no v32 tag yet. Five items are still open on the 32.0 milestone.
Merged PRโs
Every week, several changes are officially added to Bitcoin Core. This week, multiple changes were merged. Here are some I found interesting this week.
wallet, descriptor: Revert
StringType::COMPATfor Miniscript expressions and drop the concept of a Descriptor ID that can be validated by achow101achow101 closed a wallet compatibility hole that had already bitten once.
Miniscript keys were not handled
StringType::COMPATcorrectly when computing a Descriptor ID. To keep old wallets loading, Core had to keep hashing that ID the wrong way. This is the second time that happened, so this PR stops pretending the ID is something you can validate at all.The value read from the database is now an opaque blob that only ties records to a ScriptPubKeyMan.
DescriptorIDis renamed toCompatDescriptorHashโ still written, no longer checked against a recomputed hash.importdescriptorsandcreatewalletdescriptorcompare descriptor strings instead of hashes. Lookup inm_spk_managersgoes from a map tostd::find_if(log to linear). achow101โs take: those RPCs are not the hot path, andimportdescriptorsmight rescan anyway.The wallet backwards-compat test now includes 30.2 and 31.0 nodes plus a Miniscript wallet, so both directions get exercised. Fixes #35432. If you have a wallet with Miniscript in it from a previous release, this is the PR that is supposed to keep it loading.
http: throttle send buffer when client stops draining by pinheadmz
If a client stops reading the socket, Core used to keep dispatching requests and packing responses into
m_send_bufferwith no cap. After a complete request is parsed, before it goes to a worker, the server now checks that buffer. Already 32MiB sitting there (MAX_BODY_SIZE, open for bikeshedding) and the request stays asm_reqinstead of getting another worker. The misbehaving client does not get an unbounded send queue for free.This was found and disclosed by the Red Team ๐ฅ. Same HTTP rewrite pinheadmz has been triaging agent findings on โ last week he asked people to keep them coming before branch-off.
There are always changes being updated and reviewed in real-time. Here are some notable PRโs that are still up and looking for reviews.
kernel: use struct-based logging and simplify logging interface by stickies-v
sedited asked for comments in Thursdayโs meeting. stickies-v just pushed after months of architecture thrash. It is open, not a draft, not Needs rebase. Last weekโs prefetch PR (#36000) is still open too if you have a second tab.
tl;dr: kernel logging is cumbersome. This PR delivers log entries as a struct instead of a formatted string, and simplifies the kernel logging interface. Closes #34062.
Kernel logging has a few problems:
callbacks operate on formatted strings, so users need to parse the string to get the timestamp, category, level, ... based on which options are set. This is cumbersome, brittle, and inefficient.
the filtering interface is not really intuitive, requiring users to call combinations of
btck_logging_set_level_categoryandbtck_logging_enable_categorywhen they want to producedebugortracelogs.the node logging infrastructure has quite a bit more functionality than is necessary for a library.
This PR gives
bitcoinkernelits own implementation of those hooks, so it no longer depends onlogging.cpp, and upgrades the C API to deliver struct-based entries. Node logging is not changed.
IRC meeting notes
Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.
๐ณ๐ท๐ฎ๐ต๐ฟ: There are no pre-proposed meeting topics this week. Any last minute ones to add?
๐ณ๐ท๐ฎ๐ต๐ฟ: Let's start with the WGs
--- Topic 1 ---
๐ณ๐ท๐ฎ๐ต๐ฟ: #topic QA WG Update (brunoerg)
๐ฏ๐ฟ๐๐ป๐ผ๐ฒ๐ฟ๐ด: no update this week
--- Topic 2 ---
๐ณ๐ท๐ฎ๐ต๐ฟ: #topic QML GUI WG Update (johnny9dev)
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: First chunk of the staging branch was merged in
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Establishes the qml foundational pieces
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: hebasto helped a ton with the final review
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: I have drafts for the next two chunks. Both will setup the wallet disabled version of the gui.
๐ต๐ฒ๐ฏ๐ฎ๐๐๐ผ: post-merge review is always welcome; especially from python people
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: Yeah everything can be updated. Nothing has to be finalized
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: 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.
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: 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
๐ท๐ผ๐ต๐ป๐ป๐๐ต๐ฑ๐ฒ๐: That's all for now
--- Topic 3 ---
๐ณ๐ท๐ฎ๐ต๐ฟ: #topic Benchmarking WG Update (l0rinc, andrewtoth)
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: no update
--- Topic 4 ---
๐ณ๐ท๐ฎ๐ต๐ฟ: #topic Kernel WG Update (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
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: would be good to get some comments there.
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: that's all.
--- Topic 5 ---
๐ณ๐ท๐ฎ๐ต๐ฟ: That's it for the WGs afaict, anything to say about the release?
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: I think we are looking pretty decent for branch off
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: branch-off should be today, but there are still a few things in the milestone https://github.com/bitcoin/bitcoin/milestone/84
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: There does seem to be an outstanding thread in regards to private broadcast, which could be worth discussing now
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: Re what's left on the milestone, if any of those miss, they should also all be fine to backport into 32.x
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: yes
๐ณ๐ท๐ฎ๐ต๐ฟ: What's the private broadcast thread?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Should we do privatebroadcast now or milestone?
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: 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
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: I don't think there's too much to discuss on the milestone, other than, everything is looking for review
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: (or if someone thinks something is missing)
๐ณ๐ท๐ฎ๐ต๐ฟ: 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
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: fjahr: I think it's both
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: my impression is the base assumption of the feature is "no worse privacy than only connecting through tor"
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: there's one issue i think we should patch
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: not sure what we are discussing here exactly though
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: so for release, we could suggest remediations such as preferred configurations, or soft enforce them in releases. as an example
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: what do you mean with preferred configurations instagibbs?
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: 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.
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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.
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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.
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: 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
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: sedited f.e. we could encourage people who want higher assurance that they run onlynet=onion, or similar. Or maybe this is again just pure communication about privacy model
๐น๐ถ๐ด๐ต๐๐น๐ถ๐ธ๐ฒ: 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.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: ^ less inbound influence, that sort of thing yes
๐๐ถ๐ฝ๐ฎ: (I haven't followed the issues) is there much of a point to privatebroadcast if you're in -onlynet=onion -listen=0 ?
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: I think the idea was logical OR?
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: agree with sipa, there seems to be no point to the feature if that is the case.
๐น๐ถ๐ด๐ต๐๐น๐ถ๐ธ๐ฒ: sipa: correlating multiple connections originating from a node - any random outbound peer could do that.
๐๐ถ๐ฝ๐ฎ: There is a small advantage still, namely that the receiver cannot correlate it with other traffic from you.
๐๐ถ๐ฝ๐ฎ: Right.
๐น๐ถ๐ด๐ต๐๐น๐ถ๐ธ๐ฒ: *multiple transactions, not connections
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: I think this should be a binary choice. Either it works as advertised, or it doesn't and should be removed.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: "as advertised" doing all the work
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: so what are we advertising?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Yeah exactly, i agree with sedited but what guarantee are we aiming to provide
๐ณ๐ท๐ฎ๐ต๐ฟ: 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.
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: either we are talking about the guarantees we want to provide, or we are talking about some mitigation for something we can't disclose
๐๐ถ๐ฝ๐ฎ: The 31.0 release notes make some promises.
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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"?
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: If our privacy model is "honest but curious", then AFAIK we cover that. It's also about user expectations
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: but that;s hard to to communicate, and weaker
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: "what's honest but curious": they follow protocol, but write everything down, say
๐ณ๐ฎ๐ป๐พ๐๐ฎ๐ธ๐ฒ: 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. "
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: instagibbs: so, passive observer?
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: vs active probing, protcool violations
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: yeah, that seems very clear.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: darosior they follow the stated protocol
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: whatever that means
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: the prior issue we had and fixed violated this
๐๐ถ๐ฝ๐ฎ: There isn't even a well-defined "honest" behavior for nodes.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: sipa handwaving here
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: if we can't guarantee what's in those release notes, then we should not ship the feature imo.
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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.
๐๐ถ๐ฝ๐ฎ: 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.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: fanquake ok that note is wrong, two txs can be linked at the blockchain layer even with perfect impl
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: "not be linkable at the networking layer" maybe
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: instagibbs "otherwise unrelated" though
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: maybe that can be better defined
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: andrewtoth well, theyre all related :D but yes
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: sipa ok, then that. dont worry about my misuse of labels too much
๐๐ถ๐ฝ๐ฎ: instagibbs: no, i literally don't understand what you mean
๐๐ถ๐ฝ๐ฎ: 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
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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?
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: maybe the answer is "no we have no common definitions of what we're promising"
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: 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.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: let's save the risk estimation for the security team, please
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: at least for now
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: well then we want to keep the guarantees from v31 release notes?
๐ณ๐ท๐ฎ๐ต๐ฟ: We need to have some clarifying information though, the feature is called privatebroadcast so people will expect something just based on that
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: yeah, this conversation is too difficult if everything is not on the table
๐ฑ๐๐
๐๐ด: +1
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: fjahr: +1 for expectations
๐๐ถ๐ฝ๐ฎ: Maybe this needs a discussion at coredev, and a focus right now about what we can reasonable address by documentation clarification for 32?
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: ^ this
๐๐ถ๐ด๐ฒ๐ฟ๐ ๐ฎ๐ณ๐ถ๐ฎ: fjahr: +1
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: how can we focus on what we can reasonably address if we can't discuss the issues?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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).
๐ฑ๐๐
๐๐ด: 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
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: My favorite shed for the rename is -cloakedbroadcast /s
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: i don't think we should disable it, it is better than the default way to broadcast.
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: (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")
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: dzxzg issue is I'm not sure we agreed ahead of time
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: I'm confused, what's not clear about the release note there?
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: I dont read the docs
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: *ducks*
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: :D
๐๐ถ๐ฝ๐ฎ: instagibbs: well, you or your agent
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: sedited: fair
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: the docs seem to match my expectation of the feature in my head so maybe less confusion than im letting on
๐๐ฎ๐ป๐ฐ๐: I think the wording "never known" might give a false sense of security.
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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 users depending on something we cannot guarantee.
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: ah the easy part, naming things
๐ณ๐ท๐ฎ๐ต๐ฟ: -betterthanthedefaultbroadcast it is
๐๐น๐ถ๐๐ฏ๐ฟ__: -broadcast++
๐๐ถ๐ด๐ฒ๐ฟ๐ ๐ฎ๐ณ๐ถ๐ฎ: yancy: yes! given the current state of the discussion, it's VERY bold
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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.
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: a release not warning is not enough?
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: *note
๐ฒ๐๐ด๐ฒ๐ป๐ฒ๐๐ถ๐ฒ๐ด๐ฒ๐น: -notsoprivatebroadcast
๐๐ฒ๐ฑ๐ถ๐๐ฒ๐ฑ: this will have to be backported anway, so we'll have a few weeks to discuss.
๐น๐ถ๐ด๐ต๐๐น๐ถ๐ธ๐ฒ: and when we fixed the known issues, do we rename it back to "private broadcast"?
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: lightlike: -evenbetterthandefaultbroadcast
๐ฎ๐ป๐ฑ๐ฟ๐ฒ๐๐๐ผ๐๐ต: lightlike +1 - release note warning is better
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: 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.
๐๐ถ๐ด๐ฒ๐ฟ๐ ๐ฎ๐ณ๐ถ๐ฎ: how's "-veilbroadcast" since it's partial in privacy
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: release note warning should happen regardless
๐ฑ๐ฎ๐ฟ๐ผ๐๐ถ๐ผ๐ฟ: Anyways, i don't have much to add on this topic.
๐ณ๐ท๐ฎ๐ต๐ฟ: 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?
๐ณ๐ท๐ฎ๐ต๐ฟ: 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
๐ณ๐ท๐ฎ๐ต๐ฟ: (if people want a renaming)
๐ฑ๐๐
๐๐ด: 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
๐ ๐๐ฟ๐ฐ๐ต[๐บ]: Isn't the point that the transaction appears to come from a node that isn't the sender?
๐ ๐๐ฟ๐ฐ๐ต[๐บ]: So, maybe "teleportbroadcast" or "strawmanbroadcast" or smth?
๐ ๐๐ฟ๐ฐ๐ต[๐บ]: surrogatebroadcast? :p
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: temudandelion
๐ ๐๐ฟ๐ฐ๐ต[๐บ]: heh
๐ถ๐ป๐๐๐ฎ๐ด๐ถ๐ฏ๐ฏ๐: im JOKING
๐ณ๐ท๐ฎ๐ต๐ฟ: Murch: sounds still fine, as long as it's more descriptive of the mechanism rather than making promises of an end result
๐๐ฎ๐ป๐ฐ๐: shielded-broadcast is my bikeshed color
๐ณ๐ท๐ฎ๐ต๐ฟ: sipa about to suggest -minibroadcast
๐ณ๐ท๐ฎ๐ต๐ฟ: Ok, let's end the meeting with this :D
๐ณ๐ท๐ฎ๐ต๐ฟ: #endmeetingRead here for the full meeting
Releases
32.0 feature freeze was 2026-08-20. Branch-off /
v32.0rc1was targeted for 2026-09-10 and has not landed. The 32.0 milestone still has 5 open items. Latest still v31.1 / v30.3 / v29.4.
Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!
If there are any comments, suggestions, or errors, do not hesitate to reach out or comment