16:00:11 <achow101> #startmeeting 
16:00:11 <corebot> achow101: Meeting started at 2025-04-10T16:00+0000
16:00:12 <corebot> achow101: Current chairs: achow101
16:00:13 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:14 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:15 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:21 <TheCharlatan> 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:26 <cfields> hi
16:00:29 <furszy> hi
16:00:30 <Sjors[m]> hi
16:00:31 <hebasto> hi
16:00:36 <ryanofsky> hi
16:00:36 <lightlike> hi
16:00:40 <achow101> There is one preproposed meeting topic this week. Any last minute ones to add?
16:00:50 <vasild> < corebot> ... Participants should now identify themselves with '#here'
16:00:54 <sr_gi[m]> hi
16:00:54 <vasild> #here 
16:01:11 <achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
16:01:28 <pinheadmz> hi
16:01:29 <Sjors[m]> Or we're doing #here now?
16:01:40 <dzxzg> hi
16:02:13 <vasild> no idea why corebot is say that or whether it matters at all
16:02:16 <sr_gi[m]> I finished dusting and rebasing the full Erlay implementation on top of #30116, and I’m currently re-designing the functional tests to account for all the things that have changed prior to start running Warnet tests
16:02:18 <corebot> https://github.com/bitcoin/bitcoin/issues/30116 | p2p: Fill reconciliation sets (Erlay) attempt 2 by sr-gi · Pull Request #30116 · bitcoin/bitcoin · GitHub
16:02:37 <sr_gi[m]> Hoping to be done with the test before the next meeting and start with warnet
16:02:43 <glozow> hi
16:03:10 <sr_gi[m]> That's it on my end
16:03:21 <achow101> #topic Kernel WG Update (TheCharlatan)
16:03:32 <TheCharlatan> Nothing new per se this week. Still hunting for Approach ACKs for #30595, or one of the alternatives presented therein.
16:03:34 <corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
16:04:02 <TheCharlatan> Also been looking more at what we could provide for more stateless block validation to external users.
16:04:09 <TheCharlatan> That's all :)
16:04:37 <sipa_> hi
16:04:52 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:05:12 <sipa> No big things to report.
16:05:24 <sipa> #31444 remains next to review
16:05:28 <corebot> https://github.com/bitcoin/bitcoin/issues/31444 | cluster mempool: add txgraph diagrams/mining/eviction by sipa · Pull Request #31444 · bitcoin/bitcoin · GitHub
16:05:58 <kevkevin_> hi
16:06:52 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:07:04 <achow101> Back from break, will be addressing the comments and rebasing the PRs soon
16:07:17 <glozow> welcome back!
16:07:33 <achow101> #topic Legacy Wallet Removal WG Update (achow101, furszy)
16:07:45 <achow101> Rebased the PRs and addressed the comments.
16:07:51 <achow101> There's an interesting issue with #31250 where it seems to be possible to still create a legacy wallet that uses sqlite as the database.
16:07:53 <corebot> https://github.com/bitcoin/bitcoin/issues/31250 | wallet: Disable creating and loading legacy wallets by achow101 · Pull Request #31250 · bitcoin/bitcoin · GitHub
16:08:03 <achow101> Will be looking into that today. It's also still the current PR to review.
16:08:18 <achow101> #topic Multiprocess WG Update (ryanofsky)
16:08:50 <ryanofsky> Oh, not much to report. I think #31741 may be ready for merge, but not sure
16:08:52 <corebot> https://github.com/bitcoin/bitcoin/issues/31741 | multiprocess: Add libmultiprocess git subtree by ryanofsky · Pull Request #31741 · bitcoin/bitcoin · GitHub
16:09:19 <ryanofsky> Has a few acks, not sure if we are waiting for anything else. I have a topic later but not much more to say here
16:09:37 <achow101> #topic orphan resolution WG Update (glozow)
16:10:07 <glozow> I am making a lot of progress with the orphanage rewrite (it'll be from scratch, multi_index, but a lot more intuitive than the current structure)
16:10:15 <vasild> #31741 has a stale ack from hebasto, maybe a fresh ack from him would tip it more towards "is ready for merge"...
16:10:18 <corebot> https://github.com/bitcoin/bitcoin/issues/31741 | multiprocess: Add libmultiprocess git subtree by ryanofsky · Pull Request #31741 · bitcoin/bitcoin · GitHub
16:10:46 <glozow> So I will push to #31829 soon(TM), but before then, nothing to review
16:10:49 <cfields> ryanofsky: I'll give it another once-over and likely an ACK, I think you've addressed my concerns by now. Thank you :)
16:10:51 <corebot> https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
16:12:54 <achow101> #topic Adding IPC binaries to next release (https://github.com/bitcoin/bitcoin/issues/31756#issuecomment-2787113847) (ryanofsky)
16:13:02 <ryanofsky> Thanks vasild & cfields (from earlier topic)
16:13:08 <ryanofsky> I posted a comment 2 days ago https://github.com/bitcoin/bitcoin/issues/31756#issuecomment-2787113847 about some things that could be discussed here.
16:13:13 <Sjors[m]> achow101: sv2 workgroup update?
16:13:13 <ryanofsky> Summary is that previously I had wanted to add a `bitcoin-node` binary to the 29.0 release, installed in `libexec/` not `bin/` so not on PATH, identical to `bitcoind` binary except for supporting an `-ipcbind` option that could be used to enable an IPC mining interface, which is used by Sjors Stratum v2 mining client.
16:13:21 <ryanofsky> I saw the change as being minimally risky: adding a new binary not on PATH, with identical behavior and same compiled code as an existing binary, just linked differently and adding a single new feature that miners who are interested could use, and help us test and improve.
16:13:23 <Sjors[m]> Anyway it's just: man thing I'd like to see progress on is making libmultiprocess a subtree, which ryanofsky  has a separate topic for.
16:13:26 <ryanofsky> However, there were some concerns about adding the new binary before the 29.0 release, so it wasn't added. Main concern was that due to build issues which #31741 addresses, building the binary was annoying, and the thought was that we shouldn't ship a binary that few developers were even building, let alone testing.
16:13:29 <corebot> https://github.com/bitcoin/bitcoin/issues/31741 | multiprocess: Add libmultiprocess git subtree by ryanofsky · Pull Request #31741 · bitcoin/bitcoin · GitHub
16:13:32 <ryanofsky> PR #31741 which fixes those issues is probably ready for merge soon, but a number of other concerns could remain. I tried to list 5 possible concerns at the top of #31756, and am trying to determine which of these or other concerns may be blocking for a 30.0 release, and if there's anything I could do to address them.
16:13:33 <corebot> https://github.com/bitcoin/bitcoin/issues/31741 | multiprocess: Add libmultiprocess git subtree by ryanofsky · Pull Request #31741 · bitcoin/bitcoin · GitHub
16:13:34 <corebot> https://github.com/bitcoin/bitcoin/issues/31756 | RFC: Adding bitcoin-{node,gui} binaries for IPC in 30.0 release · Issue #31756 · bitcoin/bitcoin · GitHub
16:13:35 <achow101> Sjors[m]: oops didn't see you
16:13:37 <ryanofsky> If you have concerns about including a `bitcoin-node` binary in upcoming releases with an `-ipcbind` option exposing a mining interface used by a stratum v2 mining client, it'd be great if we could discuss them here or in #31756.
16:13:38 <corebot> https://github.com/bitcoin/bitcoin/issues/31756 | RFC: Adding bitcoin-{node,gui} binaries for IPC in 30.0 release · Issue #31756 · bitcoin/bitcoin · GitHub
16:14:26 <sipa> ryanofsky: so this would mean that users run either bitcoind/bitcoin-qt OR bitcoin-node/bitcoin-gui?
16:15:08 <ryanofsky> Ideally we have a wrapper binary, so users can just run `bitcoin gui` with IPC option or not
16:15:29 <sipa> right, sure
16:15:45 <ryanofsky> In any case the main thing for mining IPC interface is to add a bitcoin-node binary, bitcoin-gui is there for inconsistency but I'd be surprised if anyone used it
16:16:06 <sipa> consistency, i assume!
16:16:07 <Sjors[m]> I think the wrapper also makes it easier to explain how to use this.
16:16:25 <TheCharlatan> Sjors[m]: +1
16:16:30 <fanquake> I need to look at this all again, but are we breaking all infra again in 30.x with this wrapper bin?
16:16:47 <Sjors[m]> Without having to explain why "bitcoin-node" vs "bitcoind", just use "bitcoin" with some arguments.
16:16:53 <Sjors[m]> But that's somewhat cosmetic.
16:16:53 <ryanofsky> I don't think wrapper should break anything because it is just additive
16:17:05 <fanquake> I guess everyone calling bitcoind can just call bitcoind, and not care about anything new
16:17:15 <Sjors[m]> Exactly
16:17:27 <ryanofsky> Wrapper pr is #31375 and has had a few acks
16:17:28 <fanquake> All our bins exist at the same paths
16:17:30 <corebot> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
16:17:57 <sipa> maybe at some point, if the multiprocess world becomes the New World Order, bitcoind and bitcoin-qt could become wrapper binaries too that just invoke the corresponding multiprocess binaries
16:18:01 <fanquake> so which use are we going to document as “preferred” ?
16:18:10 <cfields> ryanofsky: do you see this as a path towards deprecating bitcoind? Or you see them always being shipped in parallel?
16:18:34 <cfields> just trying to understand the end-goal.
16:19:04 <ryanofsky> I don't imagine deprecating bitcoind and bitcoin-cli anytime soon, I don't think we would gain anything from that
16:19:27 <cfields> 👍
16:19:36 <Sjors[m]> fanquake: the most careful approach is probably do just keep bitcoind as the default in documentation.
16:19:37 <ryanofsky> But if we did decide to deprecate them, it should likely just involve moving them from one folder to another
16:19:46 <vasild> wen connect with "bitcoin gui" to an existent and running bitcoin-node?
16:20:17 <ryanofsky> vasild, that is implemented in #19461
16:20:19 <corebot> https://github.com/bitcoin/bitcoin/issues/19461 | multiprocess: Add bitcoin-gui -ipcconnect option by ryanofsky · Pull Request #19461 · bitcoin/bitcoin · GitHub
16:20:25 <fanquake> sjors: well are we shipping the workflows/setups that developers are using/testing, or not
16:20:30 <cfields> ryanofsky: or sipa's suggestion above sounds reasonable.
16:20:33 <TheCharlatan> I don't think we need to decide on that very soon either, but feel like the wrapper gives some flexibility on either choice once it comes to that.
16:20:39 <Sjors[m]> And maybe recommend "bitcoin rpc" instead of bitcoin-cli because it's easier with named args.
16:21:38 <ryanofsky> I'd like to add documentation recommending the wrapper. I guess I'm not sure where would be best, probaly somewhere in doc/?
16:22:01 <fanquake> Doesn’t it need to be all documentation?
16:22:03 <Sjors[m]> And "bitcoin -M node" for multiprocess
16:22:19 <Sjors[m]> (or daemon, forgot which one)
16:22:30 <fanquake> Otherwise we are just going to have inconsistency about how to do anything all over the place?
16:22:32 <ryanofsky> fanquake, yes, I guess I'm not familiar with what documentation we have
16:22:42 <Sjors[m]> fanquake: that way developers testing multiprocess will also test the wrapper
16:23:18 <ryanofsky> Definitely all multiprocess documentation should say use the wrapper, not use libexec binaries
16:23:58 <Sjors[m]> Maybe there's some execv issue on some platform, that's the only reason why it might be better to not immediately recommend it for bitcoind.
16:24:57 <ryanofsky> Yes that is a concern, there were execvp issues on windows
16:25:31 <fanquake> We will need to decide, otherwise we’ll be endlessly changing our docs between the various ways to run bitcoind, depending on which developer read them last
16:25:59 <TheCharlatan> ryanofsky, but this multiprocess release will not target windows yet, right?
16:26:03 <fanquake> And if it’s the “new” way, now the docs no longer work for any prior maintained version etc
16:26:10 <ryanofsky> fanquake, I think we should update all docs to recommend the wrapper, but not do anything that would break instructions
16:26:24 <ryanofsky> *break previous instructions
16:26:29 <Sjors[m]> So my suggestion would be "bitcoin" for everything except "bitcoind", and then change that to "bitcoin" in a later release.
16:27:19 <ryanofsky> There is no need to move bitcoind from bin/ to libexec/ for example, the wrapper will work either way and we do not really gain anyting by breaking old command lines
16:28:10 <cfields> if that's what the docs are going to recommend, maybe now's a good time in the release cycle to turn mp on by default in cmake?
16:28:30 <ryanofsky> I'm ok with sjors approach of keeping bitcoind in docs too if we want to start with that
16:28:55 <Sjors[m]> cfields: #31802 does that for the release
16:28:57 <corebot> https://github.com/bitcoin/bitcoin/issues/31802 | Add bitcoin-{node,gui} to release binaries for IPC by Sjors · Pull Request #31802 · bitcoin/bitcoin · GitHub
16:28:59 <Sjors[m]> but not for dev builds
16:29:09 <fanquake> why not for dev builds?
16:29:20 <Sjors[m]> Happy to change that of course.
16:29:20 <TheCharlatan> cfields that would be my preference too once 31741 is merged.
16:29:24 <Sjors[m]> Slower compilation?
16:29:41 <fanquake> Devs should be testing and using what we are shipping to end users
16:29:47 <fanquake> Install ccache
16:29:51 <cfields> +1
16:29:53 <ryanofsky> note: wrapper executable in #31375 is build regardless of any IPC / multiprocess option, so I don't see it as directly related, just an additional help
16:29:55 <Sjors[m]> Ok, I can change that on 31802
16:29:55 <corebot> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
16:30:10 <Sjors[m]> My machine is fast enough, I didn't even realise I forgot ccache for the first week :-)
16:30:12 <cfields> And docs should generally reflect what devs see with a default build.
16:30:12 <fanquake> we’re not going to flick options in Guix that no dev is testing or using locally
16:30:21 <ryanofsky> I think multiprocess is already enabled in dev build preset
16:30:50 <Sjors[m]> Oh yes, I meant that it's not on in cmake by default, but I don't konw about the dev preset.
16:31:25 <ryanofsky> Yes I would like it to be on in cmake default too
16:31:30 <Sjors[m]> But it sounds like we want it for the "default build", not just the test build?
16:31:43 <TheCharlatan> yes
16:32:41 <Sjors[m]> Will do
16:33:27 <cfields> ryanofsky: in case that recommendation sounded inconsistent, I didnt't think 31375 was in good enough shape initially and it was an unfortunate time in the release cycle, but I don't think those things are true anymore so my preference has flipped.
16:33:46 <cfields> er, 31741 sorry.
16:34:58 <ryanofsky> makes sense I think, 31741 is needed to turn it on by default, after that there's probably no reason not to turn it on by default
16:35:51 <Sjors[m]> ok, that's fine too
16:36:35 <Sjors[m]> But keep in mind that if you turn it on by default for depends, it will end up in the guix build.
16:36:44 <achow101> Any other topics to discuss?
16:37:03 <ryanofsky> Sjors[m] sorry did not want to imply turning it on by default in that PR
16:37:19 <ryanofsky> I think I think it would be a good small followup, either in your PR or another one
16:38:35 <cfields> Sjors[m]: good point. I'm not sure the question of what to ship has been hashed out yet.
16:38:56 <cfields> but I guess if the docs are recommending it...?
16:39:32 <ryanofsky> cfields, docs might just recommend using `bitcoin` executable which is not tied to multiprocess and doesnt depend on the build option or any outside dependency
16:40:45 <cfields> ok, so we could potentially ship the wrapper but not the mp stuff for 30. Not arguing for/against, but I supposse that's an option.
16:41:01 <fanquake> Isn’t the whole point of this to ship the MP stuff though?
16:41:22 <fanquake> For the mining interface?
16:41:40 <fanquake> The wrapper seems unrelated
16:41:50 <ryanofsky> I think the wrapper implemented in #31741 provides a better CLI, and it is helpful for making multiprocess features easier to use, it does both things
16:41:53 <corebot> https://github.com/bitcoin/bitcoin/issues/31741 | multiprocess: Add libmultiprocess git subtree by ryanofsky · Pull Request #31741 · bitcoin/bitcoin · GitHub
16:42:01 <TheCharlatan> wrong pr?
16:42:18 <ryanofsky> Oops #31375. Just pointing out that the implementation of the wrapper is completely independent
16:42:20 <corebot> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
16:42:21 <cfields> hope so, I don't remember reviewing that in 31741 :)
16:44:51 <achow101> Anything else to discuss?
16:45:51 <achow101> #endmeeting