16:00:10 <achow101> #startmeeting 
16:00:10 <core-meetbot> achow101: Meeting started at 2025-01-23T16:00+0000
16:00:11 <core-meetbot> achow101: Current chairs: achow101
16:00:12 <core-meetbot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:13 <core-meetbot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:14 <core-meetbot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:19 <Murch[m]> Hi
16:00:22 <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
16:00:22 <core-meetbot> achow101: Unknown command: #bitcoin
16:00:23 <hodlinator> hi
16:00:26 <Murch[m]> #here 
16:00:29 <cfields> hi
16:00:30 <sipa> hi
16:00:31 <sr_gi[m]> #here 
16:00:32 <lightlike> hi
16:00:33 <darosior> hi
16:00:33 <glozow> hi
16:00:37 <achow101> i've gotta change that bot command behavior..
16:00:39 <kevkevin> hi
16:00:41 <Sjors[m]> hi
16:00:43 <darosior> What's with the #here?
16:00:43 <abubakarsadiq> hi
16:00:43 <dzxzg> hi
16:00:54 <pinheadmz> yo
16:00:56 <Murch[m]> "achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'"
16:01:03 <achow101> It actually doesn't matter
16:01:14 <sr_gi[m]> hi then :P
16:01:16 <achow101> saying anything works just as well
16:01:17 <sipa> #here FirstLast
16:01:20 <stickies-v> hi
16:01:23 <Murch[m]> lol
16:01:27 <achow101> sipa: but that confuses the bot
16:01:31 <furszy> hi
16:01:42 <tdb3> hi
16:01:43 <achow101> anyways. there's one preproposed meeting topic this week, any last minute ones to add
16:01:43 <sr_gi[m]> #hi FirstLast mybe?
16:01:43 <core-meetbot> sr_gi[m]: Unknown command: #hi
16:01:51 <marcofleon> hi
16:02:39 <achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
16:04:09 <sipa> sr_gi[m], gleb?
16:04:21 <sr_gi[m]> Following on the experiments I was mentioning last week, I got the results for a wide range of combinations of inbounds and outbounds for fanout selection. I haven't written down the whole experiment and conclusions yet, but the results can be found here: https://docs.google.com/spreadsheets/d/1uaoJW941edzDvZiJDNvXruiRbjpHXM0TSfrTunivjJY/edit?gid=1920160722#gid=1920160722
16:04:25 <jonatack> hi (slow internet here atm, sorry)
16:04:40 <sr_gi[m]> There first two tabs should the data volume per transaction in different configurations
16:05:04 <maxedw> hi
16:05:40 <sr_gi[m]> Chatting with some folks in the office yesterday yield some interesting things to look at in order to try to reduce the latency so we could pick on the configurations that maximizes bandwidth
16:05:42 <kanzure> hi
16:06:01 <sr_gi[m]> So I'll check on some of those next.
16:06:58 <sr_gi[m]> I think Gleb also had a plan on his end but not sure if he's around
16:08:02 <sr_gi[m]> He'll share next time. That's all on my end
16:08:50 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:09:24 <brunoerg> hi
16:10:06 <sipa> sdaftuar is continuing his rebase of #28676 on top of my txgraph code (up to and including #31553)
16:10:09 <gribble> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
16:10:11 <gribble> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
16:10:12 <sipa> i hear there is progress
16:10:58 <sipa> we also did an in-person code review of a part of #31363 with him and instagibbs and glozow, hoping to get more eyes/comments soon
16:11:01 <gribble> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa · Pull Request #31363 · bitcoin/bitcoin · GitHub
16:11:12 <sipa> that's it from me
16:11:14 <glozow> There will be a review club meeting on #31363 on February 5
16:11:15 <gribble> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa · Pull Request #31363 · bitcoin/bitcoin · GitHub
16:11:20 <sipa> oooh!
16:11:55 <glozow> Can't guarantee more eyes, but can promise I will write some notes before then
16:13:13 <achow101> #topic MuSig2 WG Update (achow101)
16:13:23 <achow101> #31242 was merged. Spent a bunch of time working on #31622 and fixing the issues there. It should not be ready for review.
16:13:23 <core-meetbot> achow101: Unknown command: #31242
16:13:25 <gribble> https://github.com/bitcoin/bitcoin/issues/31242 | wallet, desc spkm: Return SigningProvider only if we have the privkey by achow101 · Pull Request #31242 · bitcoin/bitcoin · GitHub
16:13:30 <gribble> https://github.com/bitcoin/bitcoin/issues/31622 | psbt: add non-default sighash types to PSBTs and unify sighash type match checking by achow101 · Pull Request #31622 · bitcoin/bitcoin · GitHub
16:13:31 <gribble> https://github.com/bitcoin/bitcoin/issues/31242 | wallet, desc spkm: Return SigningProvider only if we have the privkey by achow101 · Pull Request #31242 · bitcoin/bitcoin · GitHub
16:13:33 <achow101> s/not/now
16:14:33 <achow101> I'll also be working on fixed test vectors for #31247 and to add to the bip
16:14:35 <gribble> https://github.com/bitcoin/bitcoin/issues/31247 | psbt: MuSig2 Fields by achow101 · Pull Request #31247 · bitcoin/bitcoin · GitHub
16:14:45 <achow101> so that's been marked as a draft for now
16:15:06 <achow101> the prs to review are #31243 and #31622
16:15:08 <gribble> 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
16:15:09 <gribble> https://github.com/bitcoin/bitcoin/issues/31622 | psbt: add non-default sighash types to PSBTs and unify sighash type match checking by achow101 · Pull Request #31622 · bitcoin/bitcoin · GitHub
16:15:25 <achow101> #topic Legacy Wallet Removal WG Update (achow101)
16:15:52 <achow101> #31495 has been getting some review and is still the pr to review
16:15:52 <core-meetbot> achow101: Unknown command: #31495
16:15:55 <gribble> 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
16:15:55 <gribble> 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
16:16:07 <darosior> bad bot
16:16:16 <achow101> and #31241 is probably rfm.
16:16:19 <gribble> https://github.com/bitcoin/bitcoin/issues/31241 | wallet: remove BDB dependency from wallet migration benchmark by furszy · Pull Request #31241 · bitcoin/bitcoin · GitHub
16:16:37 <achow101> which I'll take another look at today
16:16:55 <achow101> #topic orphan resolution WG Update (glozow)
16:17:03 <glozow> The current PR to review is #31666, the followup from #31397.
16:17:04 <gribble> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
16:17:09 <gribble> https://github.com/bitcoin/bitcoin/issues/31397 | p2p: track and use all potential peers for orphan resolution by glozow · Pull Request #31397 · bitcoin/bitcoin · GitHub
16:17:10 <bitcoin-git> [13bitcoin] 14darosior opened pull request #31727: miniscript: convert non-critical asserts to CHECK_NONFATAL (06master...062501_miniscript_nonfatal) 02https://github.com/bitcoin/bitcoin/pull/31727
16:17:23 <glozow> We spent some time this week thinking about what minimal orphanage buffs we want to incorporate in v29.0. So I will be heads down trying to get that PR up asap (as soon as I get rid of this bug 🤒).
16:18:30 <glozow> TLDR, it will make TxOrphanage no longer global; we'll have limits per-peer
16:19:01 <sipa> well, the TxOrphanage instance itself remains global, it's just the accounting that happens per peer?
16:19:13 <sipa> or do you think actually making the orphanage per-peer is simpler?
16:19:24 <glozow> sipa: yes, still a global `TxOrphanage` object
16:19:29 <sipa> alright
16:20:18 <glozow> And if anybody has any extra machines, I would appreciate testing on mainnet for this. Some debug-only nodes with`TXPACKAGES` logging would be great.
16:20:42 <glozow> vasild sent me some interesting logs a few weeks ago (thank you)
16:20:55 <instagibbs> you mean in general on master or whic hpr
16:20:55 <sipa> glozow: happy to run some, what PR/options?
16:21:06 <glozow> on top of #31666 would be best
16:21:07 <gribble> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
16:21:29 <glozow> sorry not "debug-only" haha. I mean in debug mode. Brain a bit fuzzy right now.
16:21:38 <achow101> glozow: I can setup one of my nodes to do that
16:22:02 <instagibbs> removes all logic but Assumes()
16:22:26 <darosior> I can run a mainnet node on this PR too
16:23:01 <glozow> Thank you very much!
16:23:37 <achow101> #topic Stratum v2 WG Update (sjors)
16:23:37 <glozow> That's all from me
16:23:41 <Sjors[m]> Suggested by darosior, he'll elaborate shortly. From my end, I think there's three questions that are good to discuss:
16:23:46 <Sjors[m]> 1. Are people still on board with including libmultiprocess in the release build at some point?
16:23:50 <Sjors[m]> 2. Can we do that for v29 or is it not good enough yet for a "Bitcoin Core seal of approval", even if marked experimental?
16:23:51 <achow101> Sjors[m]: oops wrong topic
16:23:58 <Sjors[m]> 3. Are the specific things still missing?
16:24:12 <achow101> #topic Adding multiprocess binaries to release build (#30975) (sjors)
16:24:13 <Sjors[m]> Well that's fine, it's about #30975
16:24:14 <gribble> https://github.com/bitcoin/bitcoin/issues/30975 | Add multiprocess binaries to release build (except Windows, OpenBSD) by Sjors · Pull Request #30975 · bitcoin/bitcoin · GitHub
16:24:15 <gribble> https://github.com/bitcoin/bitcoin/issues/30975 | Add multiprocess binaries to release build (except Windows, OpenBSD) by Sjors · Pull Request #30975 · bitcoin/bitcoin · GitHub
16:24:21 <Sjors[m]> Re (2): it will make my Stratum v2 life easier, because it allows me to stop maintaining two separate approaches for Template Provider. One version with IPC, and the original approach of shoving it all into bitcoind.
16:24:48 <darosior> Hi, stumbling upon #30975 i reached out to Sjors privately to raise concerns that it might be premature to release libmultiprocess binaries, especially a couple weeks from the release. He explained me his motivations and i suggested we should discuss it during a meeting because i was certain others would disagree and by coredev we would already be
16:24:49 <darosior> past feature freeze. I was also interested in hearing from people more familiar than i am with the status of the multiprocess project and codebase.
16:24:50 <gribble> https://github.com/bitcoin/bitcoin/issues/30975 | Add multiprocess binaries to release build (except Windows, OpenBSD) by Sjors · Pull Request #30975 · bitcoin/bitcoin · GitHub
16:25:04 <achow101> I think we should do multiprocess releases eventually
16:25:06 <fanquake> Why are you still maintaining the "shove it into core" approach, when it's clear we are never going to do that?
16:25:29 <fanquake> I left my more general thoughts about multiprocess being added to the build here: https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2610191420
16:25:39 <sipa> fanquake: thanks for commenting there
16:25:46 <Sjors[m]> fanquake: because it's the only thing that people can actually run right now, so I'll have to keep it rebased until we have an alternative
16:25:56 <ryanofsky> (my response is below that, please take a look at that too)
16:26:13 <fanquake> Could you also elaborate on who is running it right now. i.e how many users?
16:26:27 <cfields> Sjors[m]: including in v29 release seems very premature to me as it's not yet even on by default :). It's not clear to me at all who's had eyes on it.
16:26:50 <Sjors[m]> fanquake: the SRI team runs the IPC version, they have a handful of testers using a custom signet.
16:27:04 <Sjors[m]> And afaik the new Demand pool runs the regular version.
16:27:22 <Sjors[m]> I have no idea how many, if any, people use Demand pool, they're still starting up as a business.
16:27:36 <fanquake> So a single pool using the old version (experimentally I assume)
16:28:12 <Sjors[m]> fanquake: yes, it's partially a chicken-egg problem - without Bitcoin Core support Stratum v2 is dead on arrival
16:28:17 <ryanofsky> One idea is more people would use this if it were it were easier to use?
16:28:29 <sipa> i don't think Sjors[m]'s desire to maintain an alternative approach should have a bearing on this discussion, neither the reasons for doing so, but also not as an argument for why people should prioritize review
16:28:39 <Sjors[m]> And even experimenta support is a pain now.
16:28:55 <Sjors[m]> Because people have to install Bitcoin Core binaries from some random guy (me).
16:29:34 <fanquake> Sjors: I understand that, it's just unfortuante that as a side-effect of wanting to do an (external) stratum v2 project, the idea is taht core has to turn on another feature that clearly has a much wider scope, no clear plan/rollout etc
16:29:35 <achow101> I think the question is really whether multiprocess is ready enough for people to try to use it in production?
16:30:08 <fanquake> It's also unclear what we are commiting to. Is the mining interface going to be regarded as stable, if real pools are using it? Or will they just take the breakage, given it's all still experimental
16:30:25 <sipa> to me, the answer to (1) is yes, but it is obviously contingent on it getting sufficient review
16:30:26 <cfields> looking at the responses on github, I think maybe there's a disagreement/misalignment on what we're signaling when we ship a binary as part of a release.
16:30:43 <Sjors[m]> Stratum v2 is not production ready in general, so imo it's about whether it's good enough for testing. But afaik fanquake says, also. whether we're committed to maintain it.
16:31:18 <sipa> (2) is a much harder question, as it's not clear to me both how serious concerns about bugs/reviewer confidence are, and at the same time, it's not all that clear how much we lose by delaying one release
16:31:20 <fanquake> sipa: unfortunately during the life of libmultiprocess, getting sufficient reivew from anyone other
16:31:21 <Sjors[m]> I think it's perfectly fine if v29 still has bugs in it, for these pools. They'll probably need to offer Stratum v1 as a fallback for a while anyway.
16:31:27 <darosior> I agree with sipa for (1). And as far as i'm aware we aren't there yet, unfortunately.
16:31:30 <fanquake> than Russ, has seemed to be very difficult
16:31:51 <fanquake> Sjors: bugs might be fine for the pools, but no so much for our CI
16:32:00 <ryanofsky> What is (1)? I'm having problems following this discussion...
16:32:03 <Sjors[m]> As for the Mining interface, I think we should consider it unstable for a few releases. I maintain the only application that uses it, so changes aren't a problem yet.
16:32:21 <fanquake> and that is the current state of affairs, given there are multiple unsolved intermittent issues related to libmultiprocess
16:32:35 <achow101> what if we did a separate multiprocess only package, and make it very clear that that is experimental and subject to breakage and/or disappearnce?
16:32:53 <fanquake> I see that now there are some new PRs open in, https://github.com/chaincodelabs/libmultiprocess/pulls, but its unclear who is reviewing this changes?
16:32:57 <Sjors[m]> fanquake: fixing intermittend CI failures is always a good reason to wait with merging
16:33:27 <fanquake> If Russ dissapears (hopefuly not) tomorrow, are you planning on taking over maintainership libmultiprocess?
16:33:43 <Sjors[m]> That relates to my question (3) - there may be specific things that need to happen before the feature freeze, or we simply miss this release.
16:34:01 <sipa> fanquake: if we can direct people to change their approach in whatever way (unclear to what extent that's possible, but assuming we can), we can also make the change be "go review multiprocess"
16:34:11 <darosior> "I think it's perfectly fine if v29 still has bugs in it" - I don't feel very comfortable with the idea of Bitcoin Core releasing binaries that "may have bugs in them but it's fine".
16:34:22 <stickies-v> +1 darosior
16:34:31 <Sjors[m]> fanquake: I don't have the skill for it, which means I can't do much more than very basic maintainance on it.
16:34:53 <glozow> achow101: (sorry late but can we add topic v29.0 milestone today?)
16:34:55 <Sjors[m]> So that relates to my question (1)
16:35:16 <Sjors[m]> Whether we want multiprocess at all
16:35:24 <achow101> darosior: well we always "may have bugs", and we certainly defer some bug fixes to future releases once we get past a certain point in the release process
16:35:43 <fanquake> Apparently the answer has been "yes", but "not quite enough" for almost 10 years
16:35:45 <sipa> darosior: right, agree; i think the label "experimental" is fine for "this is unstable, may change, don't depend on it", for a limited amount of time; but i'm much less happy with a "this is actually not up to our review standards"
16:36:11 <darosior> achow101: sure but there is a difference between no warranty and breaking our standards.
16:36:28 <stickies-v> I don't understand the urgency in getting this merged. I think it's excellent that we're progressing multiprocess work, but rushing this in v29 seems not worth the potential costs given the number of substantiated concerns raised
16:36:32 <fanquake> achow101: sure, but at this point it's not even clear if anyone in the project other than sjors has even run this code
16:36:51 <fanquake> that alone seems like a weird place to be, to be merging this stuff
16:36:59 <sipa> fanquake: for me personally, seeing the interaction between sv2 work and multiprocess has positively changed my outlook on how useful the multiprocess work is
16:37:08 <ryanofsky> I don't understand what the harm would be exactly. This PR does not affect exiting binaries, it adds a new binary that we can label however we want to label it
16:37:34 <sipa> so actually seeing it "going somewhere" may very realistically change how reviewers deal with it
16:37:57 <Sjors[m]> ryanofsky: I opened the topic with 3 questions, so that's what (1), (2) , (3) refer to.
16:38:08 <achow101> I agree that we don't want to break any standards that we may already have, but all of the multiprocess code that has been merged and presumably reviewed to the same standard as everything else
16:38:22 <fanquake> sipa: I somewhat agree, if we have a longer term plan to actually do the process separation, in a way that gives the us the benefits of process separation. i.e currently, it's still a bitcoin-node process, if you don't care about wallet or gui etc
16:38:25 <ryanofsky> Can we do something like install it in bin/experimental/? bin/unstable/?
16:38:34 <fanquake> achow101: I don't see how that could be true if you look at the PRs in the multiprocess repo
16:38:47 <darosior> "Whether we want multiprocess at all" -> my opinion is yes for 1) being able to have external people experiment with alternative GUI / wallets in the short term and 2) being able to potentially, maybe, have more interesting process separation in the future (like one process per peer? let me dream ok!).
16:38:49 <achow101> unless the question is that this pr in particular doesn't meet review standards?
16:39:45 <darosior> "Whether we want multiprocess at all" -> plus as Pieter points out experiments with other interfaces we didn't think about in the first place.
16:39:46 <fanquake> It's a shame that this needs to be decided pre core dev. It'd be great to hash these questions out not over irc.
16:39:53 <Sjors[m]> If we ship this in v30 instead of v29 it's annoying for me.  I might delay Stratum v2 adoption by half a year, though it's certainly not completely blocked. What I'm mainly worried about is an indefinately punting of shipping this for vague reasons, as opposed to specific blocking bugs.
16:40:00 <Sjors[m]> * it might
16:40:09 <Sjors[m]> (annoying, but not end of the world)
16:40:12 <sipa> fanquake: i agree with that, i'd rather have this discussion (in addition to here) also at coredev
16:40:30 <ryanofsky> I think we can also hash this out in the actual PR. (i also do not favor IRC)
16:40:38 <glozow> should we explore shifting v29.0 dates?
16:40:43 <cfields> I like the idea of multiprocess and shipping it in the future. But imo it's not a good idea (and not consistent with our history) to ship something that's not on by default because otherwise we have no idea who's had eyes on it. And from what I understand, it's currently (if nothing else becausse libmultiprocess is not vendored) not ready to be on by default. It'd be more consistent with our process to turn it on by default at the beginning of a
16:40:43 <cfields> release cycle, have all devs dogfood it for 6 months, then discuss shipping it once we're all on the same page.
16:40:49 <darosior> Sjors[m]: yes absolutely understand this. I think it's part of a larger issue of not being able as a project to set some clear goals. I have some separate thoughts on this i might share another time.
16:41:01 <achow101> Sjors[m]: what's half a year to waiting 6 years already (or however long it's been, feels like forever)
16:41:01 <fanquake> sjors: i dissagree that we should do it, as long as there are no (known) bugs, there are other process/project issues here
16:41:24 <darosior> achow101: for multiprocess since 2017 :/
16:41:26 <fanquake> (there are still known bugs in either case)
16:41:51 <Sjors[m]> achow101: I've only worked on Stratum v2 for 1 year. I'm sure I'll still be motivated in 6 months. Probably not in 6 years.
16:42:33 <Sjors[m]> I do not posess ryanofsky level patience :-)
16:42:36 <sipa> cfields: i think i agree, but can you clarify with "on by default"? because releases only have defaults, and the options are (1) no multiprocess binaries (2) both multiprocess and classic binaries and (3) only multiprocess binaries
16:43:25 <fanquake> How we ship multiprocess is another thing that is still undecided
16:43:56 <fanquake> #31375 
16:43:56 <core-meetbot> fanquake: Unknown command: #31375
16:43:57 <ryanofsky> fanquake undecided as in not merged yet? i think we have a clear path
16:43:59 <gribble> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
16:43:59 <gribble> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
16:44:05 <cfields> sipa: I mean on by default in our buildsystem at all, ignoring the question of release. As i understand, pretty much the only realistic way to build/test now is with depends, and I don't know how many people do that. So I'm assuming that there aren't many devs interacting with it on a daily basis atm.
16:44:14 <sipa> cfields: agreed
16:44:28 <achow101> doesn't the dev-mode preset turn it on?
16:44:39 <sipa> i haven't even gotten it to work the last time i tried
16:44:42 <ryanofsky> the PR does not turn multiprocess on by default for developers
16:44:46 <fanquake> That only works with depends though, whcih isn't part of the dev mode
16:44:54 <sipa> i think we should have it on in dev builds by default before considering adding to releases
16:44:57 <ryanofsky> that would be a nice step to take at some point the future
16:45:00 <cfields> ryanofsky: right, that's my point. Imo that ordering is backwards.
16:45:06 <darosior> Yeah you need a patch to build it because of an issue with libatomic
16:45:10 <fanquake> and using libmulitprocess outside of depends, may or may not work depending on your os, see https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2610191420
16:45:13 <achow101> oh i installed libmultiprocess to my system, so dev-mode always builds with it. I don't necessarily test with it though
16:45:15 <darosior> sipa: +1
16:45:30 <sipa> fanquake: ah thanks
16:46:06 <fanquake> which is why I'm more in favour of vendoring, as it removes a whole class of issues
16:46:06 <ryanofsky> i see, so no feature can be in a release if it is not enabled by default in developer builds
16:46:36 <cfields> +1 for vendoring.
16:46:39 <sipa> ryanofsky: i think it's a reasonable bar, because we want to dogfood it actually working before shipping something, even if experimental?
16:46:44 <fanquake> ryanofsky: I think it's somewhat weird for us to be shipping things that developers are not actively building / using testing etc
16:46:52 <ryanofsky> yes, understood
16:47:00 <cfields> ryanofsky: I'm not sure that's a hard hard rule, but I think it's at least consistent with how we've done things in the past.
16:47:10 <cfields> and it makes sense to me in this case as well.
16:47:16 <darosior> +1
16:47:30 <ryanofsky> these are just new requests and I'm trying to boil them down
16:47:59 <Sjors[m]> fanquake: I agree there are "other process/project issues", but I'd like to see them enumerated so it's clear when we've resolved them. Though that itself takes time.
16:48:22 <darosior> So is there any other thing we could do that would make your life easier Sjors[m]?
16:48:34 <jonatack> It does sound like this could very much benefit from a tangible, non-risky nudge...and from 1-2 committed reviewers who may very reasonably be gating their review investment in seeing it likely to make progress (myself included, and as sipa pointed out)
16:49:34 <Sjors[m]> darosior: getting a multiprocess binary released by the Bitcoin Core project in some way is the most useful. Can be seperate from the main release.
16:49:39 <cfields> ryanofsky: fwiw, I'm using "can we turn it on for daily devs by default?" as a proxy for "is it maybe ready to ship?". And if the answer to the former is a no, then the answer to the latter seems pretty obvious to me.
16:50:02 <ryanofsky> i'd like to figure out a next step for 30975. seems like it could just enable multprocess in CI and not flip the depends default
16:50:11 <Sjors[m]> I could do that myself, but it makes little sense for me to release two binaries myself: a Bitcoin Core IPC build + a Template Provider. Then it's easier for me to keep them combined.
16:50:14 <hebasto> agree with vendoring libmultiprocess
16:50:28 <cfields> ryanofsky: Imo vendoring makes sense as a next step.
16:50:55 <sipa> agree
16:50:56 <cfields> to at least get everyone on the same page
16:50:57 <fanquake> Sjors: how what a separate from the main release build work? We aren't going to release/provide bin with unmerged/reviewed code
16:51:17 <ryanofsky> cfields, i dont' think it's a big deal to ship a new binary that may have bugs but has been reviewed is clearly labeled unstable
16:51:30 <ryanofsky> but understand if it's a minority opinion
16:52:03 <Sjors[m]> fanquake: if we vendor it, then we could guix build a bitcoin-node binary and ship that seperately?
16:52:05 <fanquake> Sjors: will the pools still use this if we tell them it's completely experimental / unstable, and the sidecar will likely need further changes / refactoring
16:53:10 <Sjors[m]> fanquake: that's already better than the status quo
16:53:12 <fanquake> Sjors: maybe, where do you want to distribute that from? A different download page on the website? github? etc
16:53:48 <Sjors[m]> Whatever is easier, the SRI documentation can point to it.
16:53:48 <achow101> it could just be in bitcoincore.org/bin and not actually on the downloads page
16:53:54 <darosior> Exactly. It seems this is just not possible. Pools want the Bitcoin Core seal of approval because of our release standard. Breaking these standards to be able to release a binary is probably not a solution to get them to run it.
16:54:08 <Sjors[m]> It would basically say "Please install Bitcoin Core from X instead of the normal place", then install the sidecar app.
16:54:22 <fanquake> RIght, so why can't SRI build and distribute this themselves?
16:54:36 <fanquake> Does this only work if it exists on bitcoincore.org
16:55:07 <fanquake> Surely bundling it with the sidecar would be even easier
16:55:10 <Sjors[m]> SRI is a Rust project, they're not going to release Bitcoin Core binaries I think.
16:55:42 <ryanofsky> I think seal of approval can mean we reviewed this we build this we tested this, but it it is unstable and may still have bugs and is clearly labeled as such
16:55:52 <Sjors[m]> Bundling a custom Bitcoin Core with a sidecar makes no sense, it's just more complicated to install than the combined binary I've been shipping.
16:56:16 <fanquake> Sjors: I mean a tarball can have both the custom core bin, and the sidecar
16:56:35 <fanquake> which also removes this distribution problem, given they are downloading the sidecar in any case
16:56:35 <sipa> fanquake: i don't know if that's all that much of a reasonable distinction
16:56:44 <cfields> ryanofsky: I think there's a difference between "this is an all-hands wip and may still be unstable" and "this has barely been dogfooded internally at all, but may be useful to some".
16:56:45 <achow101> I think we're gettinga bit off topic here, It seems like there's still unresolved issues that can probably be worked out in the pr, and things we definitely need to discuss at coredev. I'd say this will likely miss v29.
16:56:50 <sipa> if we're working on it, it must mean that we want people to use it, whether we distribute it or others
16:56:53 <achow101> there's still one more topic for today's meeting
16:56:55 <cfields> maybe I'm underestimating how many devs are playing with it on a daily basis?
16:56:58 <fanquake> sipa: right, but it seems just as easy as making as host some special binaries for them
16:57:06 <sipa> fanquake: fair
16:57:18 <sipa> but neither should be the end goal
16:57:35 <sipa> as a temporary situation, i don't care much
16:57:43 <glozow> I think we should move on if there are other topics, e.g. wg updates
16:57:51 <Sjors[m]> If I have to maintain a node binary forever, then it makes no sense for me to use the more complicated IPC variant. That only makes sense as a temporary measure, if I'm sure eventually Bitcoin Core will ship it.
16:57:51 <sipa> agree
16:58:00 <achow101> feel free to hash this out after the meeting
16:58:03 <achow101> #topic 29.0 milestone (glozow)
16:58:10 <darosior> sipa: seems like getting people to rely on temporary binaries we release may well be pretty permanent.
16:58:17 <ryanofsky> cfields, i don't understand importance of the all-hands part. there is value in us building and testing and releasing something even if not every developer has done it
16:58:23 <glozow> As per #31029. We have feature freeze scheduled for Feb 20
16:58:23 <gribble> https://github.com/bitcoin/bitcoin/issues/31029 | Release Schedule for 29.0 · Issue #31029 · bitcoin/bitcoin · GitHub
16:58:36 <glozow> That's 4 weeks away
16:58:37 <ryanofsky> s/importance/criticality/
16:59:00 <ryanofsky> but if that's the standard fine. you are just saying these things like they should be obvious to me and they are not
16:59:15 <glozow> I think it's an appropriate time to think "assuming people devote their time to X, is there a potential universe where we have X in v29.0"
16:59:35 <glozow> But also, given earlier comments in this meeting, do people feel very strongly about changing the date?
17:00:13 <achow101> could we delay feature freeze to after coredev?
17:00:15 <darosior> glozow: i don't think changing the date would help with the previous topic discussed.
17:00:28 <darosior> achow101: why?
17:00:35 <sipa> i'd prefer not changing the date
17:00:59 <sipa> and having a relaxed coredev where we can talk about bigger things, rather than last-minute things that may or may not still make it in
17:00:59 <fanquake> achow101: do you have particular PRs in mind that would benefit from delaying
17:01:11 <glozow> It's relevant to questions like "assuming people devote their time to X, is there a potential universe where we get X to a state where it could be in v29.0"
17:01:24 <achow101> darosior: i think there are things currently milestoned for 29.0 that could make it in during/after coredev
17:01:55 <cfields> ryanofsky: oh no no, i'm just giving my opinion because you asked. definitely not the standard and I didn't mean that as any kind of statement of fact. sorry if it came across that way.
17:01:56 <glozow> sipa: yeah I agree with not doing last minute things at coredev
17:02:29 <jonatack> PRs labeled as v29 milestone: https://github.com/bitcoin/bitcoin/milestone/69
17:02:51 <Sjors[m]> I would also prefer to either get multiprocess in well before the feature freeze, or wait for v30. It seems to big a change for a last minute discussion.
17:03:34 <glozow> Ok then we'll keep the date as is, and the coredev conversation can be about having it in v30
17:03:39 <jonatack> #proposedmeetingtopic release management rotation
17:03:39 <core-meetbot> jonatack: Unknown command: #proposedmeetingtopic
17:03:49 <achow101> fanquake: I think the legacy wallet removal stuff would benefit, but I don't feel that strongly
17:04:04 <achow101> anyways, we're out of time
17:04:08 <achow101> jonatack: we can do that next week
17:04:13 <glozow> jonatack: what do you mean by that?
17:04:32 <achow101> #endmeeting