16:00:09 <stickies-v> #startmeeting 
16:00:09 <corebot> stickies-v: Meeting started at 2026-05-21T16:00+0000
16:00:10 <corebot> stickies-v: Current chairs: stickies-v
16:00:11 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:12 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:13 <maxedw> hi
16:00:14 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:15 <janb84> hi
16:00:16 <pseudoramdom> hi
16:00:20 <_andrewtoth_> hi
16:00:21 <stickies-v> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields danielabrozzoni darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sliv3r__ sr_gi tdb3 theStack
16:00:21 <stickies-v> TheCharlatan vasild willcl-ark
16:00:22 <dzxzg> hi hi hi
16:00:23 <fjahr> hi
16:00:24 <sedited> hi
16:00:25 <marcofleon> hi
16:00:26 <jurraca> hi
16:00:27 <eugenesiegel> hi
16:00:28 <hebasto> hi
16:00:28 <dergoegge> hi
16:00:29 <kevkevin> hi
16:00:30 <stringintech> hi
16:00:33 <vasild> hi
16:00:34 <epicleafies> hi
16:00:42 <hodlinator> hi
16:00:45 <jarolrod> Hi
16:00:49 <pinheadmz> yo yo yo
16:00:53 <instagibbs> 👋
16:00:55 <Murch[m]> hi
16:00:56 <stickies-v> There are no pre-proposed meeting topics this week. Any last minute ones to add?
16:01:19 <johnny9dev> hi
16:01:27 <abubakarsadiq> hi
16:01:45 <stickies-v> cool, let's get started with the working groups
16:01:50 <stickies-v> #topic Fuzzing WG Update (dergoegge)
16:01:51 <dergoegge> no update
16:01:59 <stickies-v> #topic Kernel WG Update (sedited)
16:02:10 <theStack> hi
16:02:13 <jonatack> hi
16:03:12 <sedited> released a new rust-bitcoinkernel version with hand-rolled bindings instead of the previous auto-generated ones (reducing our build-time dependencies).
16:03:19 <darosior> hi
16:03:40 <sedited> Other than that, maybe stickies-v has something?
16:04:04 <stickies-v> he doesn't
16:04:15 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:04:25 <_andrewtoth_> A bug with leveldb has been reported https://github.com/bitcoin/bitcoin/issues/35298.
16:04:25 <_andrewtoth_> A potential fix is in https://github.com/bitcoin-core/leveldb-subtree/pull/61.
16:04:25 <_andrewtoth_> l0rinc also discovered the fix improves reindex-chainstate speed on HDDs by 17%.
16:04:25 <_andrewtoth_> Downside is around 11% more disk usage measured from the peak of disk usage. Right now an IBD will be 12 GB, this PR increases to 15 GB. But for already synced nodes the increase in disk usage will be very gradual.
16:04:25 <_andrewtoth_> Disk usage can be brought back down with a manual -forcecompactdb after sync, but I think we should just accept a little more disk usage on chainstate for not rewriting the entire db every hour.
16:04:28 <_andrewtoth_> Any thoughts on this?
16:05:02 <brunoerg> hi
16:05:24 <cfields> hi
16:05:27 <fanquake> Can you tldr the bug? My understanding is that we are thrashing peoples disks by continually re-writing (100s GB) chainstate?
16:05:35 <Murch[m]> This significantly increases the minimum disk space necessary for a pruned node :-/_
16:05:36 <Murch[m]> s/:-/_/:-/\/
16:05:57 <stickies-v> also wdym 12GB IDB disk usage? that seems... low?
16:05:59 <_andrewtoth_> Seek compaction is a mechanism that will compact files in leveldb due to lots of reads
16:06:09 <Murch[m]> stickies-v: Just for the UTXO set
16:06:19 <stickies-v> oh, i see. thx
16:06:29 <_andrewtoth_> since we do few writes, but lots of reads, it causes all written files to be compacted down to the lowest level
16:06:56 <_andrewtoth_> this was happening daily before v30, but v30 writes a small file every ~hour now
16:07:11 <_andrewtoth_> it was still a bug doing it every day, but now it's even worse
16:07:41 <Murch[m]> Can the count of reads permitted before compaction be increased?
16:07:41 <_andrewtoth_> the purpose of seek compaction was for old spinning disks that took 10ms to seek to a file
16:08:10 <_andrewtoth_> Murch: possibly, was suggested by willclark
16:08:33 <_andrewtoth_> another option is to make forcecompactdb an RPC, which can be called periodically
16:09:09 <Murch[m]> Would it be possible to turn that feature off in general and just call it ~once per week?
16:09:10 <_andrewtoth_> but for backports, we can suggest to users to run forcecompactdb after a full sync
16:09:42 <_andrewtoth_> I don't think it's worth calling it once per week. The amount of new data written every week is < 200MB or so. And that would rewrite the whole db every week.
16:09:59 <_andrewtoth_> I think if users notice the increase in disk usage, they can call it then?
16:10:14 <Murch[m]> I see, but it would gradually bloat the chainstate by about ~25% over time?
16:10:33 <_andrewtoth_> 11% over time, from peak disk usage at that point
16:10:57 <_andrewtoth_> peak usage of chainstate historically was, like 13.5 GB? so an IBD will be 11% more than that
16:11:07 <_andrewtoth_> if you run today, you will have a compacted db, so it will be 11% more than today
16:11:13 <Murch[m]> Ah, I see, that’s where the 15 GB comes from
16:11:45 <sedited> Re-writing it once a week seems fine though?
16:11:56 <dzxzg> what about enabling compaction for dbcache full flushes and disabling it for the interval flushes?
16:12:17 <darosior> Tweaking this parameter in our LevelDB forks would only affect disk usage, not performance at all?
16:12:20 <abubakarsadiq> > but for backports, we can suggest to users to run forcecompactdb after a full sync
16:12:20 <abubakarsadiq> Why can't we automate this in the backport patch?
16:12:25 <fjahr> How sure are we 11% is really the peak? I assume there were a few measurements so far but it could still be worse on some systems/circumstances we may be missing?
16:12:51 <darosior> Could also just do it on startup if that's easier than setting a timer?
16:13:15 <_andrewtoth_> This issue in particular does not want it done at startup https://github.com/bitcoin/bitcoin/issues/29662
16:13:49 <_andrewtoth_> re: performance, there will be some more files in the db tree, but we have bloom filters for all of them so skipping is cheap
16:14:39 <_andrewtoth_> sedited: I think not rewriting it is the intended operation of leveldb. If users care about 11% less disk space (which we have >100x than chainstate in blocks dir), they can run the option?
16:15:08 <_andrewtoth_> dzxzg: that would be dependent on the user's dbcache setting as well
16:15:33 <Murch[m]> Well, not rewriting 10 GB every hour seems like the most pressing aspect of this.
16:15:35 <_andrewtoth_> it is my opinion that seek compaction is a bug and should just be removed
16:15:59 <darosior> Doing what LevelDB considers normal operations and having a mechanism to optimize disk space (whatever it is) sounds good to me.
16:17:10 <_andrewtoth_> abubakarsadiq: i don't think we should automate it, I think we should just report to the users there may be higher disk space, and run forcecompactdb if desired
16:17:15 <darosior> By mechanism giving the option to user, either as a startup option or an RPC command.
16:17:20 <yancy> hi
16:17:29 <darosior> By mechanism i mean*
16:17:31 <_andrewtoth_> The startup option is already there, but I think RPC is more ideal
16:17:43 <_andrewtoth_> but, for backports the startup option is fine
16:18:42 <Murch[m]> If there is already a startup option, an RPC shouldn’t be a too heavy lift, I take it
16:18:55 <_andrewtoth_> Murch: yes, I believe l0rinc is already working on that
16:19:28 <_andrewtoth_> fjahr: there are measurements in the PR, and a more lengthy explanation
16:19:45 <abubakarsadiq> _andrewtoth_: My question was why? Specifically, I assume everyone is going to desire more disk space; is there an implication of doing so that we want users to opt into or not?
16:19:48 <Murch[m]> Interesting issue. Your mitigation approach sgtm then
16:19:51 <_andrewtoth_> I don't think it can get worse, but more eyes would be good
16:20:33 <Murch[m]> abubakarsadiq: My understanding is that users are worried about the increased writes exhausting their SSDs’ limited write capability
16:20:53 <_andrewtoth_> abubakarsadiq: the trade off is more disk IO. It will rewrite 10s of GBs each time. It will really only save 3GB if you did a fresh IBD. Otherwise, you will be rewriting everything for not much savings.
16:21:34 <dzxzg> esp. for pruned nodes: i assume that if people are running with prune=650  they might care
16:21:34 <Murch[m]> _andrewtoth_: Maybe one automatic compaction at the end of IBD would make sense
16:21:50 <stickies-v> yeah one after IBD seems like a sane default?
16:22:12 <stickies-v> would prefer not adding an rpc for this if we can avoid it
16:22:44 <abubakarsadiq> _andrewtoth_: Murch[m]: makes sense now, thanks.
16:23:01 <darosior> I think the startup option should be enough yes
16:23:10 <darosior> Doing it after IBD sounds good too
16:23:15 <_andrewtoth_> can we track if a user did from genesis easily, and then got to tip?
16:23:22 <stickies-v> leveldb is an implementation detail and exposing it through our public stable interface is a bit messy
16:23:26 <cfields> +1 on avoiding an rpc. I think the number of people who will be able to use that knowingly and correctly is single-digits.
16:24:00 <darosior> AFK
16:24:18 <Murch[m]> Lunch? ^^
16:24:19 <stickies-v> even startup option i would probably find overkill, unless there is clear demand for it
16:24:51 <_andrewtoth_> ok, having the startup option exists undocumented already, but we can find a way to do compaction first time the user gets to tip.
16:24:55 <cfields> stickies-v: agreed. Same for any option. If we can't decide when to do it automatically, we shouldn't expect a user to be able to know when to do it manually.
16:25:07 <abubakarsadiq> +1 cfields: I think if we can make that decision for users, it's more ideal
16:25:16 <Murch[m]> +1 cfields
16:26:13 <stickies-v> anything else here _andrewtoth_ ?
16:26:21 <_andrewtoth_> Closed #31132 and reopened as #35295. Got some good review there that I need to address (thanks!), more review welcome. That's it from me, thanks!
16:26:26 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:26:28 <corebot> https://github.com/bitcoin/bitcoin/issues/35295 | validation: fetch block inputs in parallel during ConnectBlock by andrewtoth · Pull Request #35295 · bitcoin/bitcoin · GitHub
16:26:49 <stickies-v> thanks for the comprehensive overview, sounds like you got some useful feedback
16:27:01 <stickies-v> #topic Silent Payments WG Update (Novo__)
16:27:42 <theStack> The libsecp SP module PR https://github.com/bitcoin-core/secp256k1/pull/1765 got some momentum and fresh reviewer eyes after coredev (thanks!). In core, Novo__ opened #35301 and #35302 now (second takes of previously #28122 and #28201, respectively) based on that. Review would be much appreciated.
16:27:44 <corebot> https://github.com/bitcoin/bitcoin/issues/35301 | Silent Payments: Implement bip352 (take 2) by Eunovo · Pull Request #35301 · bitcoin/bitcoin · GitHub
16:27:45 <corebot> https://github.com/bitcoin/bitcoin/issues/35302 | Silent Payments: Sending (take 2) by Eunovo · Pull Request #35302 · bitcoin/bitcoin · GitHub
16:27:49 <corebot> https://github.com/bitcoin/bitcoin/issues/28122 | Silent Payments: Implement BIP352 by josibake · Pull Request #28122 · bitcoin/bitcoin · GitHub
16:27:52 <corebot> https://github.com/bitcoin/bitcoin/issues/28201 | Silent Payments: sending by josibake · Pull Request #28201 · bitcoin/bitcoin · GitHub
16:29:12 <johnny9dev> Sorry I have to get going. Here is my qml update. https://github.com/orgs/bitcoin-core/projects/1/views/3 is updated. We're making steady progress and still on track to have the project in a state where we feel it is worthwhile to start getting feedback from a wider group in the middle/end of June.
16:29:16 <stickies-v> #topic QML GUI WG Update (johnny9dev)
16:29:50 <stickies-v> #topic Libevent removal (pinheadmz, fjahr)
16:30:06 <pinheadmz> Ironing out edge cases in #35182. Running fuzzers 24/7.
16:30:09 <corebot> https://github.com/bitcoin/bitcoin/issues/35182 | Replace libevent with our own HTTP and socket-handling implementation by pinheadmz · Pull Request #35182 · bitcoin/bitcoin · GitHub
16:30:14 <pinheadmz> Antithesis caught something that I thought I fixed, but actually just triggered it again this morning doing a DoS test. It's an assertion in the destructor which I think we can relax, and just delete connections that are taking to long (>60s) to close. Might needs hodlinator 's opinion on that before pushing...
16:30:25 <pinheadmz> Janb84 grok-claude caught something which is not hard to fix but is harder to test because of all the nasty global state in httpserver.cpp, so trying to figure out what to include in this PR and what to punt to a follow up. Definitely the first follow-up de-globalizing http will be a very satisfying refactor.
16:30:42 <pinheadmz> fjahr ?
16:31:10 <fjahr> I just keep addressing review comments on the #34342 as quickly as possible. It feels like it’s getting very close though, thanks to the reviewers :)
16:31:14 <corebot> https://github.com/bitcoin/bitcoin/issues/34342 | cli: Replace libevent usage with simple http client by fjahr · Pull Request #34342 · bitcoin/bitcoin · GitHub
16:32:38 <stickies-v> alright, looks like that's it for this week's WG updates
16:32:41 <stickies-v> Anything else to discuss?
16:32:46 <jurraca> a few ASmap things
16:32:53 <jurraca> looking for one more ACK on https://github.com/bitcoin-core/asmap-data/pull/48
16:32:59 <jurraca> opened a PR to merge the prototype asmap.sigs repo into bitcoin-core/asmap-data as discussed at CoreDev https://github.com/bitcoin-core/asmap-data/pull/50
16:33:09 <jurraca> and next collab run is set for June 4th, two weeks from today https://github.com/bitcoin-core/asmap-data/issues/51
16:34:42 <Murch[m]> The CI workers seem to be very slow for the BIPs repository this morning. I assume that this also applies to the Bitcoin Core PRs. Anyone know what’s going on there?
16:35:30 <fanquake> I wanted to bring up #35319
16:35:32 <corebot> https://github.com/bitcoin/bitcoin/issues/35319 | net: use the proxy if overriden when doing v2->v1 reconnections by vasild · Pull Request #35319 · bitcoin/bitcoin · GitHub
16:35:35 <instagibbs> +1 fanquake
16:35:40 <fanquake> My understanding is that "normal" -privatebroadcast usage might actually just leak your IP.
16:35:44 <fanquake> I'm wondering if we should alert users in some way (mailing list / website?).
16:35:52 <fanquake> Seems reasonable if there was some expectations of privacy here
16:36:16 <Murch[m]> Also, for any BIP authors in this chat. I started the BIP metadata review that was future work for the BIP3 deployment. If you have any Informational BIPs that should be Specification BIPs, you will probably see a PR in that regard (or can open it yourself!). Similarly any BIPs that have been in Draft for years, will be proposed to be moved to Complete or Closed where applicable, or further input will be sought.
16:36:19 <fanquake> Also there doesn't yet seem to be consensus on how to fix / test
16:36:33 <Murch[m]> So, if you want to help, it would be awesome if you look over your own BIPs in that regard.
16:38:02 <instagibbs> +1 on some communication at least, brand new opt-in feature so impact is hopefully limited
16:38:09 <eugenesiegel> there are a couple different tests, I haven
16:38:15 <sedited> instagibbs can you provide a tldr?
16:38:17 <Murch[m]> fanquake: What dose "normal" mean in this regard? I thought this happens when a connection downgrades from BIP324 to legacy P2P traffic?
16:38:46 <instagibbs> sedited: on v2->v1 downgrade (if peer fails the v2 connection), if we're using Tor exit node, we leak our ip directly to that target peer
16:39:24 <instagibbs> It's broken unless you connect to honest v2 peers, in other words
16:39:31 <instagibbs> or hidden service nodes
16:39:49 <_andrewtoth_> or honest v1 nodes
16:40:06 <_andrewtoth_> *any v1 nodes
16:40:17 <fanquake> (and I guess assume that spies will start trying to exploit given it's public knowledge)
16:40:37 <eugenesiegel> there are a couple different tests, I haven't taken a look at instagibbs latest test. I'm partial to any functional test that can test without modifying the non-test code. as far as fixes, I think passing around an optional that defaults to nullopt kind of encourages callers to forget to set it? so maybe we could make it explicit? vasild patch does
16:40:37 <eugenesiegel> work, just thinking how to make it robust
16:40:40 <_andrewtoth_> really only malicious v2 nodes on clearnet
16:41:37 <Murch[m]> Doesn’t even require a v2 node, you just have to fudge your service bits
16:41:39 <instagibbs> eugenesiegel I made an attempt at robust test-only code changes
16:42:14 <instagibbs> but I'm not a net expert, hoping more people look
16:42:29 <eugenesiegel> Murch: right, a third party could also do it for some peers
16:43:48 <instagibbs> "or honest v1 nodes" no, you leak your ip address to honest v1 nodes, you just hope no one looks at logs :)
16:44:01 <instagibbs> oh, if bits arent stuffed, rigth
16:44:48 <_andrewtoth_> instagibbs: you leak your ip for v1 nodes too? but it's using the proxy and not downgrading?
16:44:51 <Murch[m]> Wait, it always fails with v1 peers? I thought only on downgrade. That makes it way worse.
16:45:20 <instagibbs> I retract my claim, need to re-page in how that part works
16:45:41 <cfields> I know it's waaay out of scope, but I mentioned this a few time at CoreDev... private tx relay would've been a great opportunity to launch separate short-lived tor-only instances of CConnman/PeerManager to handle the broadcast. I suspect that we continue to hit edge-cases otherwise :(
16:46:27 <cfields> Just something to consider for the future.
16:47:14 <eugenesiegel> It only fails on downgrade afaict and with a specific -proxy option. Though if there are v1 peers, a third party could modify service bits and force you to connect v2 and then downgrade
16:47:51 <eugenesiegel> So, "-proxy=127.0.0.1:9050" is safe. "-proxy=127.0.0.1:9050=tor" is not safe
16:50:09 <eugenesiegel> I have no idea on how widespread the feature is, I think sparrow uses it? I think a mailing list post could be helpful to tell people about the issue
16:50:48 <_andrewtoth_> What is the behavior with default proxy options? So unset by the user?
16:52:57 <eugenesiegel> _andrewtoth_: I'm not sure, does a user need to set -proxy to enable tor?
16:53:15 <_andrewtoth_> no, and default is "disabled" according to bitcoind -h
16:54:01 <_andrewtoth_> default also allows making pb connections to clearnet via exit nodes
16:55:08 <eugenesiegel> how does bitcoind know the control port then? is it set to the default?
16:56:24 <instagibbs> 4 minutes left (this conversation needs to continue anyways)
16:56:27 <stickies-v> i'm going to call end of meeting here since we're coming up on time, feel free to continue ofc. thanks for contributing, everyone
16:56:35 <stickies-v> #endmeeting