--- Log opened Thu Jan 30 00:00:06 2025
00:01 < _aj_> (dropped from the design, i mean, not much value implementing it with the orphanage as it is currently)
00:01 < glozow> yeah, it didn't add much value with the current orphan reso method
00:02 < glozow> It's more helpful in the package relay world
00:10 < _aj_> maybe make it PackageRequestTracker (where an orphaned child implies the pacakge of the child and its missing parents) and use it for making orphan handling efficient, and generalise it more as package relay progresses further? not having that and ending up with O(n^2) stuff doesn't seem surprising; that was what ~exactly the tracker was there to fix
00:52 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:26 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has joined #bitcoin-core-dev
02:02 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
02:06 < bitcoin-git> [bitcoin] maximevtush opened pull request #31761: Update LICENSE (master...master) https://github.com/bitcoin/bitcoin/pull/31761
02:07 < bitcoin-git> [bitcoin] fanquake closed pull request #31761: Update LICENSE (master...master) https://github.com/bitcoin/bitcoin/pull/31761
03:03 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
03:06 -!- Talkless [~Talkless@mail.dargis.net] has quit [Client Quit]
03:29 -!- MyNetAz [~MyNetAz@user/MyNetAz] has quit [Remote host closed the connection]
03:31 -!- MyNetAz [~MyNetAz@user/MyNetAz] has joined #bitcoin-core-dev
03:32 < instagibbs> > O(log(peers*peer_orphan_count_limit)) 
03:32 < instagibbs> it's this afaict, but if peer_orphan_count_limit is large, this ends up being substantial, especially if if you have ~120  inbounds
03:38 -!- jespada [~jespada@2800:a4:2225:fa00:219b:97a5:1505:5c5f] has joined #bitcoin-core-dev
03:45 < bitcoin-git> [bitcoin] Sjors opened pull request #31763: Pass custom DEP_OPTS and CONFIG_FLAGS to guix-build (master...2025/01/guix-config-flags) https://github.com/bitcoin/bitcoin/pull/31763
04:04 -!- eval-exec [~Thunderbi@23.106.134.43.16clouds.com] has joined #bitcoin-core-dev
04:10 -!- eval-exec [~Thunderbi@23.106.134.43.16clouds.com] has quit [Quit: eval-exec]
04:12 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
04:20 -!- eval-exec [~Thunderbi@23.106.134.43.16clouds.com] has joined #bitcoin-core-dev
04:27 -!- dni [~dni@64.226.100.125] has joined #bitcoin-core-dev
04:33 < bitcoin-git> [bitcoin] hebasto opened pull request #31764: cmake: Generate man pages at install time (master...250130-man-install) https://github.com/bitcoin/bitcoin/pull/31764
04:38 -!- BrandonOdiwuor [~BrandonOd@105.163.157.80] has joined #bitcoin-core-dev
04:48 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
04:53 -!- jespada [~jespada@2800:a4:2225:fa00:219b:97a5:1505:5c5f] has quit [Ping timeout: 244 seconds]
04:57 < bitcoin-git> [bitcoin] hebasto closed pull request #31764: cmake: Generate man pages at install time (master...250130-man-install) https://github.com/bitcoin/bitcoin/pull/31764
04:57 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has joined #bitcoin-core-dev
05:14 < bitcoin-git> [bitcoin] hebasto opened pull request #31765: cmake: Install man pages for built targets only (master...250130-man-inst) https://github.com/bitcoin/bitcoin/pull/31765
05:31 -!- dni [~dni@64.226.100.125] has quit [Ping timeout: 240 seconds]
05:50 -!- ajonas [uid385278@id-385278.helmsley.irccloud.com] has joined #bitcoin-core-dev
05:59 -!- Guest25 [~Guest25@ppp-49-237-12-244.revip6.asianet.co.th] has joined #bitcoin-core-dev
06:00 < bitcoin-git> [leveldb-subtree] fanquake opened pull request #47: Fix C++23 compilation errors in leveldb (bitcoin-fork...cpp_std_23) https://github.com/bitcoin-core/leveldb-subtree/pull/47
06:01 < bitcoin-git> [bitcoin] fanquake opened pull request #31766: [WIP] leveldb: pull upstream C++23 changes (master...leveldb_cpp23) https://github.com/bitcoin/bitcoin/pull/31766
06:09 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
06:27 -!- Guest25 [~Guest25@ppp-49-237-12-244.revip6.asianet.co.th] has quit [Quit: Client closed]
06:36 < instagibbs> 🦄
06:39 -!- johnny9dev584508 [~johnny9de@136.56.172.142] has quit [Ping timeout: 245 seconds]
06:47 -!- johnny9dev584508 [~johnny9de@136.56.172.142] has joined #bitcoin-core-dev
06:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:51 -!- johnny9dev584508 [~johnny9de@136.56.172.142] has quit [Client Quit]
07:07 -!- johnny9dev584508 [~johnny9de@136.56.172.142] has joined #bitcoin-core-dev
07:19 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
07:20 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has joined #bitcoin-core-dev
07:22 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has quit [Client Quit]
07:27 -!- robszarka [~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0] has joined #bitcoin-core-dev
07:31 -!- rszarka [~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0] has quit [Ping timeout: 276 seconds]
07:33 -!- eval-exec [~Thunderbi@23.106.134.43.16clouds.com] has quit [Ping timeout: 248 seconds]
07:36 -!- midnight [~midnight@user/midnight] has quit [Remote host closed the connection]
07:37 -!- midnight [~midnight@user/midnight] has joined #bitcoin-core-dev
07:38 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has quit [Read error: Connection reset by peer]
07:38 -!- cman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has joined #bitcoin-core-dev
07:40 -!- rszarka [~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0] has joined #bitcoin-core-dev
07:43 -!- robszarka [~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0] has quit [Ping timeout: 260 seconds]
07:48 < achow101> jonatack: wanted to check that you no longer want to talk about the "release management rotation" you proposed at the end of last week's meeting
08:00 -!- Emc99 [~Emc99@212.129.76.76] has joined #bitcoin-core-dev
08:00 < glozow> hi
08:00 < tdb3> hi
08:00 < achow101> #startmeeting
08:00 < corebot> achow101: Meeting started at 2025-01-30T16:00+0000
08:00 < corebot> achow101: Current chairs: achow101
08:00 < corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
08:00 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1001] has quit []
08:00 < instagibbs> hallo
08:00 < corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
08:00 < corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
08:00 < achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
08:00 < jonatack> achow101: not at this time, ty
08:00 < jonatack> hi
08:00 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1001] has joined #bitcoin-core-dev
08:00 < TheCharlatan> hi
08:00 < kevkevin> hi
08:01 < sr_gi[m]> Hi
08:01 < hebasto> hi
08:01 < ajonas> hi
08:01 < darosior> hi
08:01 < achow101> There are 2 preproposed topics this week. Any last minute ones to add?
08:01 < brunoerg> hi
08:01 < kevkevin> #here
08:01 < sipa> hi
08:01 < pinheadmz> yo
08:01 < darosior> #here \" DROP TABLE actions
08:01 < Sjors[m]> hi
08:01 < cfields> hi
08:01 < hodlinator> hi
08:01 < achow101> darosior: rude
08:01 < lightlike> hi
08:01 < achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
08:02 < fjahr> hi
08:02 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit []
08:03 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
08:03 < sr_gi[m]> Following from last week’s meeting, I mentioned that after running a wide range experiment with different combinations of parameters for how to select fanout peers, a less static approach was proposed by @murch: instead of having a fixed fanout rate (selecting some inbounds and outbounds), we could have a variable rate based on how the peer has received the transaction
08:03 < abubakarsadiq> hi
08:03 < furszy> hi
08:04 < sr_gi[m]> This tries to guess how propagated the transaction is to use more fanout or more reconciliation to keep propagating it
08:05 < sr_gi[m]> It is something we previously tried by checking how many peers may have announced a transaction by the time we needed to pick to how many peers to fanout to, but that approach, while promising, didn't seem to work too well
08:05 < sr_gi[m]> Long story short, @murch suggestion yield really interesting results
08:05 < sr_gi[m]> Reducing the transaction propagation latency by a significant bit while not affecting the bandwidth too much
08:06 < sr_gi[m]> A full explanation of the approach, experiment, results and conclusions can be found here, for those interested: https://srgi.notion.site/Define-the-transaction-fanout-rate-based-on-whether-the-node-has-received-the-transaction-via-fanout-18a7b3fef9778097a922fac307125de2#18a7b3fef97780b59ebbfede420d76d7
08:08 < jonatack> nice
08:08 < sr_gi[m]> Next is to decide if modifying the poisson timers for erlay, in order to achieve better latency, is acceptable, and to what extend, or if we could find an alternative solution that may be less intrusive 
08:08 < sr_gi[m]> That's it on my end
08:09 < achow101> #topic Kernel WG Update (TheCharlatan)
08:09 < TheCharlatan> I don't have much to share this week, but stickies-v published a python wheel https://www.piwheels.org/project/py-bitcoinkernel/ for the pip package https://pypi.org/project/py-bitcoinkernel/ for wrapping the proposed kernel API. 
08:09 < TheCharlatan> Seems like some people already are using them for gathering transaction and block data.
08:09 -!- Murch[m] [~murch@user/murch] has changed host
08:10 < abubakarsadiq> nice, this is more convenient to use 
08:10 < TheCharlatan> Other than that I am looking for review on #31382.
08:10 < sipa> #31382
08:10 < corebot> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan · Pull Request #31382 · bitcoin/bitcoin · GitHub
08:10 < TheCharlatan> ty :)
08:12 < achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
08:12 < sdaftuar> oh hi
08:13 < sdaftuar> my update is that i was able to rebase my big PR on sipa's work, so #28676 can be looked at to get an idea of how sipa's code will be used
08:13 < corebot> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
08:13 < Murch[m]> Hi  (think I wasn’t authed earlier)
08:13 < sdaftuar> i still need to do more cleanups on my branch, so leaving it in draft (as sipa's PRs still need review anyway)
08:13 < sdaftuar> that's it from me
08:14 < achow101> #topic Stratum v2 WG Update (sjors)
08:14 < instagibbs> I've been taking a peek, thanks sdaftuar
08:14 < glozow> thanks sdaftuar!
08:14 < Sjors[m]> There's a Matrix chat for the work group, that's mostly quiet
08:14 < Sjors[m]> But you can dm your Matrix username to be added there. Or we can try another platofmr.
08:14 -!- BrandonOdiwuor [~BrandonOd@105.163.157.80] has quit [Quit: Client closed]
08:15 < Sjors[m]> #31756 is a good followup of last weeks discussion
08:15 < corebot> https://github.com/bitcoin/bitcoin/issues/31756 | RFC: multiprocess binaries in 29.0 · Issue #31756 · bitcoin/bitcoin · GitHub
08:15 < Sjors[m]> I'm personally not assuming we'll meet the v29 release, but it would be good to continue the discussion there so we're on the same page for e.g. v30
08:16 < Sjors[m]> Next on peoples review list, suggested: #31283
08:16 < corebot> https://github.com/bitcoin/bitcoin/issues/31283 | Add waitNext() to BlockTemplate interface by Sjors · Pull Request #31283 · bitcoin/bitcoin · GitHub
08:16 < Sjors[m]> That's the last bit of the interface.
08:16 < Sjors[m]> The interface and getting multiprocess in A release is pretty much all that's needed.
08:18 < achow101> #topic MuSig2 WG Update (achow101)
08:18 < abubakarsadiq> nice I will take a look! @sjors[m] I see you rebase your branch on #31384, can we have the 29.0 milestone on it?
08:19 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
08:19 < achow101> No update really, been a bit incapacitated this week. Still planning to write some psbt test vectors soon(tm)
08:19 < achow101> The next pr to review is #31243
08:19 < corebot> https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 · Pull Request #31243 · bitcoin/bitcoin · GitHub
08:19 < Sjors[m]> abubakarsadiq: that milestone only makes sense if we still aim for v29
08:19 < achow101> #topic Legacy Wallet Removal WG Update (achow101)
08:20 < achow101> #31241 was merged. The next pr is #31495 which looks like there is some review I need to address.
08:20 < corebot> https://github.com/bitcoin/bitcoin/issues/31241 | wallet: remove BDB dependency from wallet migration benchmark by furszy · Pull Request #31241 · bitcoin/bitcoin · GitHub
08:20 < corebot> achow101: Error: That URL raised <Connection timed out.>
08:20 < achow101> Other than that, not much else
08:20 < sipa> #31495
08:20 < corebot> https://github.com/bitcoin/bitcoin/issues/31495 | wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases by achow101 · Pull Request #31495 · bitcoin/bitcoin · GitHub
08:21 < abubakarsadiq> Milestone for  
08:21 < abubakarsadiq> #31384
08:21 < corebot> https://github.com/bitcoin/bitcoin/issues/31384 | mining: bugfix: Fix duplicate coinbase tx weight reservation by ismaelsadeeq · Pull Request #31384 · bitcoin/bitcoin · GitHub
08:21 < achow101> #topic orphan resolution WG Update (glozow)
08:21 < glozow> I'm working on my per-peer orphanage branch, which is maybe 80% of the way there.
08:21 < glozow> (80%TM)
08:22 < sipa> the second 80% might take less than the first 80%
08:22 < glozow> I'm trying to get #31666 merged soon as it's based on that. A little bit of active discussion left on the the AddChildrenToWorkset assignment, happy to punt that or defend it
08:22 < corebot> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
08:23 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has joined #bitcoin-core-dev
08:23 < glozow> sipa: haha. I'm going a little bit back and forth on the count limits thing, might just end up incorporating the struct memory usage after benching it
08:23 < glozow> anyway I hope to have my PR up soon
08:24 < sipa> glozow: happy to discuss more
08:24 < glozow> I might actually trim things like "give outbounds more space than inbounds" to make it smaller / more realistic for v29
08:24 < glozow> sipa: thanks
08:24 < sipa> as in 400 kWU for everyone?
08:24 < glozow> yes
08:25 < sipa> do we have a way of gathering data whether or not that would affect any actual tx relay right now?
08:26 < instagibbs> I asked timo but he's busy this week, so if anyone has high quality node data
08:26 < glozow> hmmm, is the best way to analyze that to measure how many bytes peers use right now?
08:26 < instagibbs> (read: not randomly shutting machines off like mine)
08:26 < sipa> glozow: i think so
08:26 < glozow> my byte accounting code seems correct(TM), we could start running that now
08:27 < glozow> well this can also be inferred from the `getorphantxs` RPC results
08:27 < instagibbs> beneficial to make sure logging is decent for 29.0. whatever happens?
08:27 < instagibbs> I expect it to be very bursty
08:28 < glozow> yeah i expect it to be very high at first, and then taper off
08:28 < glozow> idea: orphanage can borrow some space from mempool when it's not full?
08:28 < glozow> (maybe we should continue this later? meeting can go on?)
08:29 < instagibbs> ✅
08:29 < sipa> let's discuss after
08:29 < achow101> #topic mutation testing (brunoerg)
08:29 < brunoerg>  Hi, just a quick announcement that I’m performing mutation testing and publishing the reports at bitcoincore.space. I do it based on master branch once a week (every Monday, I guess) and then I update the website with the results
08:29 < brunoerg>  I started to do it on more important/critical part of the codebase (pow, tx_check, script interpreter, etc) but I intend to expand it soon. Any suggestions for function/code file to include next on it, let me know.
08:30 < brunoerg> that's it
08:30 < sipa> you run that website?
08:30 < brunoerg> yes
08:30 < achow101> how are you generating mutations? by hand?
08:30 < brunoerg> no, using my own tool
08:30 < brunoerg> https://github.com/brunoerg/mutation-core
08:31 < darosior> Nice.
08:31 < sipa> nice site
08:31 < achow101> neat
08:32 < achow101> #topic What should be the mid to long term goals of the project? (darosior)
08:32 < achow101> this sounds like a question for coredev
08:32 < darosior> Hi, see https://antoinep.com/posts/core_project_direction for the longer version but here is the TL;DR. With limited resources there is an upper bound on the amount of stuff the project can maintain. We can pay in either a limited project scope or a reduced overall software quality but we can't have it for free.
08:32 < darosior> Resources are also spread inequally. It's very hard to onboard and make meaningful impact in important areas. With key people leaving or reducing their involvement we've at best had constant resources despite an increasing number of contributors. Despite this, the scope of the project has been constantly increasing.
08:32 < darosior> Bitcoin Core cannot be the "everything Bitcoin app" without also diluting priorities. Not doing anything about it is making this choice by default. Finally, defining a scope is not only about pruning stuff. It can also help us shift focus toward things we would see as in-scope but not making enough progress.
08:32 < darosior> For the purpose of this meeting i'm interested in:
08:32 < darosior> 1. do people make the same observation / agree with the problem statement in the first place?
08:32 < darosior> 2. do people agree that defining a scope / long term vision for the project is an appropriate solution?
08:32 < darosior> 3. hearing about others' thoughts about this issue.
08:32 < darosior> Note i obviously do not expect to find a solution in a single IRC meeting. But i think it's good to kick off the discussion here, and continue it at Coredev.
08:32 < darosior> achow101: yes but i figured it could be helpful to start the discussion here
08:34 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
08:35 < Sjors[m]> In what areas has the scope been increasing in e.g. the last 5 years though?
08:35 < glozow> I agree it's hard to do the topic justice in this meeting. appreciate that you're posting this here ahead of coredev
08:35 < Sjors[m]> There's been 0 new GUI features, IIRC only a handful of new RPC calls.
08:35 < sipa> i have many thoughts about this, but i'll try to organize them before coredev
08:36 < Sjors[m]> There's certainly a desire to increase scope in various places, but this often goes nowhere because - as you point out - we're already quite stretched.
08:36 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:36 < achow101> have a few thoughts on this as well, will also try to organize them before coredev
08:37 < glozow> I disagree the scope hasn't increased - "a handful of RPCs" in the last 5 years is around 50. the security requirements certainly have increased
08:37 < darosior> Sjors[m]: i don't want to make this a discussion about "should we drop  the GUI", although removing it from the main project could definitely be part of defining a scope.
08:37 < abubakarsadiq> @sjors[m] this might be an indicator that the gui is not getting much improvements
08:38 < TheCharlatan> darosior beyond the three questions you are asking is there further homework we could be doing to be better prepared when discussing in person?
08:39 < darosior> Sjors[m]: it's pretty obvious the project has been getting bigger in any metric one can think of, and you static you are not seeing that is an illustration of the issue we are facing here.
08:39 < darosior> s/static/stating
08:39 < sipa> I think RPCs are a bad metric for measuring scope creep, dilution, or lakc of focus (all of which are real problems we suffer from). The actual maintenance cost for most RPCs, on a per-RPC basis, is small; the cost is in the code subsystem behind it.
08:40 < glozow> Right, should we be preparing our thoughts on what we think the goals should be + to what extent we think we should/can be planning?
08:40 < darosior> TheCharlatan: thanks for asking, yes i think it would be nice if we all thought about "What should be the scope of the project", "What should be Bitcoin Core's mission", so we can get inputs from as many people as possible for this discussion
08:40 < glozow> er yes, agree number of RPCs is not that meaningful, I just had a nitpick moment
08:40 < jonatack> i've had concerns for some time now about the collectivist "we" approach, particularly in a project where decentralization is the fundamental value
08:40 < fanquake> Sjors: I have a hard time agreeing with no scope increase. If we haven't increased our scope at all, what are the hundreds of thousands of new lines of code for
08:41 < Sjors[m]> I'm using a fairly narrow defination of scope, things like features and functionality.
08:41 < achow101> perhaps the first exercise is to define "scope"
08:41 < Sjors[m]> But if you mean "scope" as in things people work on, then there's more, that would include refactors.
08:41 < darosior> jonatack: yeah i agree with that, but also individual actions have negative externalities on the project at large and we need collective actions to work against them.
08:41 < sipa> I also disagree that an expanding scope is *necessarily* a problem. I believe it's a natural consequence of shifting interesting in a software being developed, even if no prioritization/focus issues existed.
08:42 < lightlike> what would help is concrete example of stuff that has been merged in the past but wouldn't / shouldn't have been merged with a "scope".
08:42 < sipa> lightlike: yes, making this concrete helps for the purpose of discussion.
08:43 < fanquake> lightlike: I think it's less things wouldn't have been merged, and more we need to face the reality that we can't keep adding new stuff with continued brain drain/flat-if-not-declining engineering capacity
08:43 < darosior> jonatack: there is a balance to strike between "everyone work on their stuff and the project decays" and "some people decide what everybody else should be spending their time on"
08:43 < sipa> darosior: agreed
08:43 < darosior> achow101: yes i agree, when thinking about this i found that defining scope would be the first step to then layout a set of priorities and then take action upon those priorities
08:44 < fanquake> we are already shipping things that you could consider unmaintained. i.e a GUI that doesn't work out of the box on one of the platforms we support (macOS)
08:44 < sipa> fanquake: yes, but i think the correct thing to look at is concrete examples that cause us maintenance cost. I believe there can exist maintained, fully functional, but not being-developed, features in the codebase, which do not cause the project a high cost.
08:44 < sipa> While there are other examples of things that exist in a half-finished state, which interact with lots of other things, and possible detract review power from other, more impactful things.
08:45 < sipa> So I think it's important to keep this concrete, and not just look at the codebase and "look, more RPCs, more lines of code, bad!".
08:45 < darosior> lightlike: yes i can try to compile a list of things that should have seen more focus and others that should have seen less before Coredev, but this is necessarily going to be stepping on eggs
08:45 < fanquake> sipa: possibly, but that doesn't solve the issue that the poeple that wrote that code are dissapearing, and the new people don't understand/can't maintain it if needed
08:45 < sipa> fanquake: that's fair, but i don't think this applies to the vast majority of the codebase
08:46 < fanquake> sure, but it applies to the most important parts
08:46 < glozow> I think we could focus more on how we spend resources + existing efforts to increase resources. That could potentially be a more productive conversation, though there are no easy solutions
08:46 < sipa> so, i'd like to encourage people to come up with specific examples
08:47 < ajonas> Coredev or here, I think the format to have this discussion is a challenge. Venting is healthy but there have been attempts to address meta-level project improvements in the past and it's hard to get to meat of it or come to any concrete steps going forward. It'd be great if there were ideas to discuss this in something other than a 1-to-N way where most people stay silent.
08:47 < Sjors[m]> darosior: bring eggs :-) it's good to have examples as a starting point
08:48 < sipa> We should discuss this on a meta-level too of course, but there is only so much talk can accomplish. Actually talking about specific projects can help people focus on them (for review, or for discussion on deprecation/removal/moving out alike!), and ultimately that is the only thing that will change things.
08:48 < jonatack> darosior: when in doubt, I think the balance to strike is in favor of decentralizad, ad hoc, less process
08:48 < laanwj> is the gui broken on macos?
08:49 < darosior> jonatack: this is a bunch of undefined terms that are not helpful to take concrete actions
08:49 < fanquake> laanwj: yes, it is unsable for any non-technical user, due to lack of notarization/codesigning issues
08:49 < achow101> fanquake: there's literally a pr for that
08:49 < fanquake> yes, with literally 0 review
08:49 < darosior> achow101: that has seen no review
08:49 < laanwj> fanquake oh, that, i was afraid it'd be another qt issue but that seems kind of meta
08:49 < darosior> ie, nobody cares enough
08:49 < achow101> fanquake: you're one of 2 people with the macos code signing key, you're the reviewer
08:50 < darosior> haha
08:50 < fanquake> we can't claim that we need to have feature x, but at the same time nobody is reivewing the changes needed to ship feature x
08:50 < fanquake> achow101: I don't see how who has the signing keys is relevant here
08:50 < sipa> fanquake: i think it's important to distinguish between "we should have feature X", and "hey guys we talked about feature X, it seems people want it, can it be reviewed please?".
08:51 < darosior> Alright, i guess i've done my advertisement. Please everyone do a bit of thinking about the issue before Coredev so we all participate in this discussion and finally are able to take actions. We have been talking about this for years now.
08:51 < fanquake> sipa: sure. I guess here I am talking about things we already have, which are just degrading
08:51 < sipa> fanquake: i'd really like you to be specific :)
08:51 < fanquake> sipa: the macOS gui
08:51 < Sjors[m]> I do occasionally review those macOS signing key PRs, but they're often impossible to test without signatures.
08:51 < fanquake> which doesn't work
08:52 < Sjors[m]> IIRC I asked for those a while back, but can check again.
08:52 < achow101> fanquake: a code signature from a code signer makes reviewing code signing changes easier/possible
08:52 < sipa> ok, who here uses macOs?
08:52 < fanquake> achow101: sure, if someone pings me for one in that PR I can provide, as can the other signer
08:52 < Sjors[m]> And I use the macOS GUI all the time
08:52 < laanwj> the only mac is have is old and support for its version of macos was dropped so i can't help in that regard, at least not with testing
08:52 < sipa> achow101: what's the PR?
08:53 < achow101> #31407
08:53 < jonatack> I have a recent mac
08:53 < corebot> https://github.com/bitcoin/bitcoin/issues/31407 | guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries by achow101 · Pull Request #31407 · bitcoin/bitcoin · GitHub
08:53 < darosior> Let's not derail the discussion into specifics
08:53 -!- greypw149508 [~greypw@user/greypw] has quit [Remote host closed the connection]
08:54 < Sjors[m]> And I know people run into lack of codesigning for the daemon too, see #29749. 
08:54 -!- greypw149508 [~greypw@user/greypw] has joined #bitcoin-core-dev
08:54 < laanwj> it's just that discussion about reducing scope always goes into "drop the gui" and "drop the wallet" which happen to be the parts i find very importnat
08:54 < achow101> laanwj: indeed
08:55 < Sjors[m]> Indeed, and the wallet is also a useful  reference for other projects. See e.g. recent revival of PSBTv2 review.
08:55 < jonatack> Regarding the specific case of the GUI, getting funding for working on it has been a non-starter for years, perhaps somewha partially  related to moving out of the bitcoin core repo  
08:55 < jonatack> laanwj: achow101: agree
08:55 < glozow> Ok so I think the meat here is "we seem to have lots of people, but people are not spending their energy on the right things. There are parts of the codebase that deserve significantly more/less attention than they're getting now. That can be dangerous for particularly important areas." I think we should come prepared to talk about what those specific areas are *with a specific focus on areas that require more attention, not less*. And think 
08:55 < glozow> about why we personally don't work on certain things. Perhaps people naturally haven't learned much about an area. Obviously we have limited time. Maybe people are not incentivized/encouraged to do so (I don't just mean economically but that is part of it).
08:55 < darosior> jonatack: to be more concrete as to your concern which i would interpret as keeping enough "emergent process" in the project, i think this is desirable and not contradictory with defining a scope. Also, we can only take collective action about the scope of the project if there is rough consensus about said scope. If there is not, i don't think it
08:55 < darosior> will be possible to take action. I also think it would be a pretty bad outcome for the project.
08:55 < laanwj> re the gui, one reason for me losing the joy of working on it were these kind of discussions, it's always on the chopping block
08:56 < laanwj> has been since 2012 or so
08:57 < Sjors[m]> laanwj: it also just really hard to work with qt5. I'm hoping either QML + QT6 or multiprocess and external GUI will get things moving again eventually. 
08:57 -!- PaperSword1 [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
08:57 < hebasto> further gui development requires expanding dependencies. it’s another concern
08:58 < laanwj> in any case, i agree with keeping limit on scope creep in general, that's also what i've always tried, not every random RPC or GUI feature anyone asks for needs to be added, but i don't think that's the case either
08:58 -!- PaperSword [~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 252 seconds]
08:58 -!- PaperSword1 is now known as PaperSword
08:58 < sipa> laanwj: agreed, it's not like we willy nilly take on extra features; "seems too tangential, can be done elsewhere" has long been a reason not to take things
08:58 < darosior> Alright, thanks everyone for chiming in. I'll try and compile more thoughts and data/examples about this issue.
08:59 < laanwj> hebasto: yeah, i tried limiting the build-time dependencies with my qtsowrap work last year, but there was almost no attention for it
08:59 < sipa> laanwj: :(
08:59 < sipa> i really liked that idea, but i also don't use the GUI
08:59 < lightlike> glozow: there is no real guidance for newer contributors as to which areas of the codebase would need more attention. maybe a good thing would be if some experienced contributors would just publish a list of areas that they think could  need more attention.
08:59 < jonatack> laanwj: I empathize
09:00 < laanwj> well it has to be updated for qt6 anyhow, that should go first
09:00 < sipa> laanwj: another idea i've seen more recently is the possibility with multiprocess of having a few-dependency (maybe statically built) core, and having a gui binary connect to it with more dependencies
09:00 < laanwj> but if we yet again go "oh maybe we should drop the gui" i find it hard to invest time in it
09:00 < laanwj> sipa: that would make sense
09:00 < jonatack> lightlike: yes. in general, I like the idea of contributors expressing these things in personal blog posts (rather than, say, in core dev documentation or processes)
09:00 < sipa> so that everyone still uses the same release core binary, focusing testing/review, but if you want to use the gui, you take on the (inevitable) cost of having more dependencies too
09:01 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
09:01 < fanquake> statically built core is certainly already possible, it's just somewhat of a mess to integrate without somewhat overhauling how we build releases, as we'll likely need to split into separete non-gui and gui builds
09:01 < achow101> I believe we're getting a bit off topic and into the weeds, so I'll end the meeting here. Feel free to continue discussing.
09:01 < achow101> #endmeeting
09:01 < corebot> achow101: Meeting ended at 2025-01-30T17:01+0000
09:01 < corebot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-30_16_00.log.json
09:01 < corebot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-30_16_00.log.html
09:01 < corebot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-30_16_00.html
09:01 < fanquake> (to get have less complication / get the benefits of not having to boostrap all the qt deps in the build where they aren't needed)
09:02 < achow101> fanquake: #31407 changes the workflow for macos code signers. I think it's completely reasonable, and in fact required, for at least one of, if not both of, the macos code signers to review and test it
09:02 < corebot> https://github.com/bitcoin/bitcoin/issues/31407 | guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries by achow101 · Pull Request #31407 · bitcoin/bitcoin · GitHub
09:02 < achow101> not to mention that it also requires additional credentials to be gotten from apple, which afaik, you're the only one who can do that.
09:02 < fanquake> sipa: it's not even the cost of more deps, it's stuff like, us upgrading our fuzzing/test infra a new LLVM is blocked because some qt (or dep) doesn't compile
09:03 < darosior> Yes there is risks to users, but the costs are mostly for maintenance and future work
09:03 < sipa> fanquake: by "cost of deps" i mostly meant as a user, you get the cost of increased security surface
09:03 < fanquake> the cost of features just get externalized to people working on other parts of the code
09:03 < Sjors[m]> Is there an index for https://bitcoincore.org/depends-sources ?
09:03 < glozow> lightlike: I agree! And I was intimidated by certain projects/areas after learning about them, maybe others have a similar experience but idk. Perhaps we can do more to help people move out of their comfort zones
09:04 < sipa> fanquake: of course for maintenance dependencies have a cost too, but that's inherent to having a GUI in the first place
09:04 < bitcoin-git> [bitcoin] danielabrozzoni opened pull request #31767: rpc: Ensure -debug=0/none behaves consistently with -nodebug (master...debug_flag_consistency) https://github.com/bitcoin/bitcoin/pull/31767
09:05 < darosior> Multiprocess will also make it possible to have different software that live in completely separate repositories. This would make it possible for people interested in working on one process to make progress, and possibly even iterate faster, without imposing cost on contributors interested in the node process.
09:05 < fanquake> sipa: sure, but also not GUI specific, which is why we've generally pushed back on deps
09:05 < sipa> fanquake: absolutely
09:05 < glozow> great, so why isn't everybody working on multiprocess?
09:05 < darosior> glozow: yes
09:05 < darosior> Exactly this. Defining long term goals would help.
09:06 < sipa> glozow: probably because... everybody sees it's not moving fast, so it's unclear to individual contributors how much their personal decision to contribute will have impact
09:06 < achow101> Sjors[m]: I don't think so, and setting one up would be non-trivial at this time.
09:06 < sipa> yay for self-fullfilling prophecies
09:06 < Sjors[m]> achow101: ok, I'm trying to see if capnp is there, but I'm not sure what the URI would be. I'll try some guesses.
09:07 < fanquake> glozow: probably the same reason most contributors were not working on the high priority for review items
09:08 < glozow> I think before we tackle "why aren't other people working on the important things" we should fully grok "why haven't I been working on the things I claimed were important to me"
09:08 < fanquake> or other deemed-high-priority-for-the-project project
09:09 < sipa> jonatack: re decentralization, i think it's important to distinguish between coordination and control. I fully believe that nobody gets to decide what anyone works on. If someone has their own pet peeve project that they want to keep working on, and aren't interested in working on anything else, that's their right. But if nobody else is interested in reviewing/helping with it, that person should 
09:09 < sipa> also accept it might not go anywhere. Coordination is about...
09:09 < sipa> trying - for people who want - to find common grounds for things that might have sufficient critical mass to make progress, so time can be spent on those.
09:10 < darosior> sipa: It's not because something is being worked on and gets reviewed that it needs to live in Bitcoin Core.
09:10 < sipa> darosior: that is true too, but that's part of the review process
09:11 < darosior> sipa: there is a conflict about "right" here. It's as much the right of other contributors (especially maintainers) to not bear the cost of more stuff being added, as the right of people to work on what they want.
09:11 < fanquake> That is also hard though, because it's unclear for reviewers (especially new ones) how to decide what should/shouldn't live in Core, without any real guidance.
09:11 < sipa> darosior: i think that's a matter of speaking up
09:11 < sipa> (which, we definitely don't do enough)
09:12 < fanquake> (also because it's easier to ignore things than actually NACK)
09:12 < sipa> fanquake: indeed
09:12 < darosior> Not everyone affected by the costs of adding more stuff get to say it in the review process. Plus the cost is dispersed among everyone, current and future contributors, whereas the benefits of "getting my stuff merged in Bitcoin Core" are concentrated.
09:12 < sipa> but a review comment of the form "this unduly increases the maintenance burden for the project" is fully valid
09:12 -!- Emc99 [~Emc99@212.129.76.76] has quit [Quit: Client closed]
09:13 < darosior> sipa: yes but it's often too small to warrant blocking something individually, but it adds up
09:14  * darosior lunch
09:14  * sipa lunch
09:27 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
09:28 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
09:34 < instagibbs> 99.94% of txns seen in my orphanage are <=4kWU, 99.99% by 16kWU, 100% by 40kWU
09:39 < jonatack> sipa: yes, I think for coordination when in doubt prefer ad hoc, informal, opt-in, organic, bottom up, lighter, less
09:40 < instagibbs> (well, maybe 5 9's, not 100%)
09:56 -!- andytoshi [~apoelstra@user/andytoshi] has quit [Ping timeout: 244 seconds]
09:56 < lightlike> instagibbs: are you running with #31666, and if so, do you see whether your orphanage is smaller on average compared to before, due to more orphans being resolved quickly?
09:58 < instagibbs> don't have those stats handy, my first pass was to look at the average case tx size, so if we go to per peer limits, in practice the storage capacity will go way up
10:02 < lightlike> i see. i did getorphantxs before updating to #31666 (it was pretty well populated, at least 50 entries) and after (empty / almost empty) but it's just anecdotal (not enough datapoints). 
10:02 < Murch[m]> Could someone please ban https://github.com/Aldocapurro from the org? The account has been spamming empty reviews for a few days
10:02 < corebot> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
10:03 -!- andytoshi [~apoelstra@user/andytoshi] has joined #bitcoin-core-dev
10:05 < instagibbs> lightlike yeah I think scraping logs and doing some comparisons there would make sense?
10:07 < lightlike> or just calling getorphantxs  and getting the count every 10 minutes, both pre- and after #31666.
10:07 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:07 < instagibbs> you could poll more often and count how many are "stuck" based on their age and reasonable lifespan
10:10 < instagibbs> ~2.5% of my node's total orphan bytes came from txns >4kWU, to normalize the statistic a bit
10:19 < achow101> Murch[m]: they've been blocked
10:19 < Murch[m]> achow101: Thanks
10:22 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
10:32 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
10:36 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
10:43 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
10:45 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has joined #bitcoin-core-dev
10:55 < glozow> instagibbs: thanks for checking, now wondering if these pesky inbounds even deserve 400kwu
10:58 < instagibbs> being the same amount is simpler...
10:58 < glozow> true
10:58 < glozow> also, I guess more accurate would be to look at the orphans that actually become useful. theoretically there could be a lot of small ones because somebody is already doing the "lots of tiny orphans" attack
10:59 < instagibbs> yeah my data didnt actually filter for resolved orphans, which would be more interesting
10:59 < glozow> not to knock the very helpful data
11:01 < bitcoin-git> [bitcoin] brunoerg opened pull request #31768: test: check `scanning` field from `getwalletinfo` (master...2025-01-test-wallet-scan) https://github.com/bitcoin/bitcoin/pull/31768
11:07 < instagibbs> though if we're regularly under attack by small orphan tx griefers, we already are hosed :)
11:10 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 248 seconds]
11:10 -!- PaperSword1 [~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-dev
11:13 -!- PaperSword1 is now known as PaperSword
11:16 -!- MyNetAz [~MyNetAz@user/MyNetAz] has quit [Remote host closed the connection]
11:17 -!- MyNetAz [~MyNetAz@user/MyNetAz] has joined #bitcoin-core-dev
11:30 -!- Guest26 [~Guest26@2a09:bac5:7cab:1cd2::2df:c4] has joined #bitcoin-core-dev
11:35 -!- Guest26 [~Guest26@2a09:bac5:7cab:1cd2::2df:c4] has quit [Client Quit]
11:48 -!- kevkevin [~kevkevin@23-127-18-192.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev
12:03 -!- PaperSword1 [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
12:05 -!- PaperSword [~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 260 seconds]
12:05 -!- PaperSword1 is now known as PaperSword
12:26 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:34 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
12:40 -!- kevkevin [~kevkevin@23-127-18-192.lightspeed.cicril.sbcglobal.net] has quit [Remote host closed the connection]
13:34 -!- jespada [~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb] has quit [Ping timeout: 246 seconds]
13:50 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:59 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
13:59 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds]
14:01 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
14:24 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
14:25 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
15:17 -!- tstearns [~tstearns@partridge.tstearns.net] has quit [Ping timeout: 276 seconds]
15:18 -!- vasild [~vd@user/vasild] has quit [Remote host closed the connection]
15:18 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
16:11 -!- andytoshi [~apoelstra@user/andytoshi] has quit [Ping timeout: 244 seconds]
16:14 -!- andytoshi [~apoelstra@user/andytoshi] has joined #bitcoin-core-dev
16:20 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
16:27 -!- pyth [~pyth@14.161.171.123] has joined #bitcoin-core-dev
16:34 < bitcoin-git> [bitcoin] ryanofsky pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/809d7e763cc9...8fa10edcd170
16:34 < bitcoin-git> bitcoin/master 8888ee4 MarcoFalke: ci: Allow build dir on CI host
16:34 < bitcoin-git> bitcoin/master 8fa10ed Ryan Ofsky: Merge bitcoin/bitcoin#31428: ci: Allow build dir on CI host
16:34 < bitcoin-git> [bitcoin] ryanofsky merged pull request #31428: ci: Allow build dir on CI host (master...2412-ci-build) https://github.com/bitcoin/bitcoin/pull/31428
16:48 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
16:52 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
17:26 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 264 seconds]
18:50 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
18:54 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
19:15 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
20:16 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 248 seconds]
20:53 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
22:01 -!- emcy__ [~emcy@148.252.144.118] has joined #bitcoin-core-dev
22:04 -!- mcey_ [~emcy@148.252.144.118] has quit [Ping timeout: 260 seconds]
22:30 -!- BrandonOdiwuor [~BrandonOd@105.163.157.80] has joined #bitcoin-core-dev
23:53 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-dev
23:55 -!- S3RK_ [~S3RK@user/s3rk] has quit [Ping timeout: 246 seconds]
--- Log closed Fri Jan 31 00:00:04 2025