brunoerg has quit [Remote host closed the connection]
jonasschnelli_ has joined #bitcoin-core-dev
marcofleon_ has joined #bitcoin-core-dev
hebasto_ has joined #bitcoin-core-dev
steven has joined #bitcoin-core-dev
RubenSomsen_ has joined #bitcoin-core-dev
infernixx has joined #bitcoin-core-dev
nickler_ has joined #bitcoin-core-dev
sipa_ has joined #bitcoin-core-dev
stevenroose has quit [*.net *.split]
infernix has quit [*.net *.split]
hebasto has quit [*.net *.split]
_koolazer has quit [*.net *.split]
RubenSomsen has quit [*.net *.split]
marcofleon has quit [*.net *.split]
jonasschnelli has quit [*.net *.split]
nickler has quit [*.net *.split]
sipa has quit [*.net *.split]
hebasto_ is now known as hebasto
RubenSomsen_ is now known as RubenSomsen
marcofleon_ is now known as marcofleon
infernixx is now known as infernix
kevkevin has joined #bitcoin-core-dev
koolazer has joined #bitcoin-core-dev
kevkevin_ has joined #bitcoin-core-dev
kevkevin has quit [Read error: Connection reset by peer]
Christoph_ has quit [Quit: Christoph_]
Christoph_ has joined #bitcoin-core-dev
Zenton has quit [Ping timeout: 244 seconds]
Zenton has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] sr-gi opened pull request #32245: doc: Updates how to reproduce fuzz CI failure locally (master...2025-04-update-fuzzmd) https://github.com/bitcoin/bitcoin/pull/32245
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
<achow101>
There is one preproposed meeting topic this week. Any last minute ones to add?
<vasild>
< corebot> ... Participants should now identify themselves with '#here'
<sr_gi[m]>
hi
<vasild>
#here
<achow101>
#topic Erlay WG Update (sr_gi, gleb, marcofleon)
<pinheadmz>
hi
<Sjors[m]>
Or we're doing #here now?
dzxzg has joined #bitcoin-core-dev
<dzxzg>
hi
<vasild>
no idea why corebot is say that or whether it matters at all
<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
<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
<achow101>
#topic orphan resolution WG Update (glozow)
<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)
<vasild>
#31741 has a stale ack from hebasto, maybe a fresh ack from him would tip it more towards "is ready for merge"...
<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.
<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.
<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.
<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.
<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.
<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.
<sipa>
ryanofsky: so this would mean that users run either bitcoind/bitcoin-qt OR bitcoin-node/bitcoin-gui?
<ryanofsky>
Ideally we have a wrapper binary, so users can just run `bitcoin gui` with IPC option or not
<sipa>
right, sure
<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
<sipa>
consistency, i assume!
<Sjors[m]>
I think the wrapper also makes it easier to explain how to use this.
<TheCharlatan>
Sjors[m]: +1
<fanquake>
I need to look at this all again, but are we breaking all infra again in 30.x with this wrapper bin?
<Sjors[m]>
Without having to explain why "bitcoin-node" vs "bitcoind", just use "bitcoin" with some arguments.
<Sjors[m]>
But that's somewhat cosmetic.
<ryanofsky>
I don't think wrapper should break anything because it is just additive
<fanquake>
I guess everyone calling bitcoind can just call bitcoind, and not care about anything new
<Sjors[m]>
Exactly
<ryanofsky>
Wrapper pr is #31375 and has had a few acks
<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
<fanquake>
so which use are we going to document as “preferred” ?
<cfields>
ryanofsky: do you see this as a path towards deprecating bitcoind? Or you see them always being shipped in parallel?
<cfields>
just trying to understand the end-goal.
<ryanofsky>
I don't imagine deprecating bitcoind and bitcoin-cli anytime soon, I don't think we would gain anything from that
<cfields>
👍
<Sjors[m]>
fanquake: the most careful approach is probably do just keep bitcoind as the default in documentation.
<ryanofsky>
But if we did decide to deprecate them, it should likely just involve moving them from one folder to another
<vasild>
wen connect with "bitcoin gui" to an existent and running bitcoin-node?
<fanquake>
sjors: well are we shipping the workflows/setups that developers are using/testing, or not
<cfields>
ryanofsky: or sipa's suggestion above sounds reasonable.
<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.
<Sjors[m]>
And maybe recommend "bitcoin rpc" instead of bitcoin-cli because it's easier with named args.
<ryanofsky>
I'd like to add documentation recommending the wrapper. I guess I'm not sure where would be best, probaly somewhere in doc/?
<fanquake>
Doesn’t it need to be all documentation?
<Sjors[m]>
And "bitcoin -M node" for multiprocess
<Sjors[m]>
(or daemon, forgot which one)
<fanquake>
Otherwise we are just going to have inconsistency about how to do anything all over the place?
<ryanofsky>
fanquake, yes, I guess I'm not familiar with what documentation we have
<Sjors[m]>
fanquake: that way developers testing multiprocess will also test the wrapper
<ryanofsky>
Definitely all multiprocess documentation should say use the wrapper, not use libexec binaries
<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.
<ryanofsky>
Yes that is a concern, there were execvp issues on windows
<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
<TheCharlatan>
ryanofsky, but this multiprocess release will not target windows yet, right?
<fanquake>
And if it’s the “new” way, now the docs no longer work for any prior maintained version etc
<ryanofsky>
fanquake, I think we should update all docs to recommend the wrapper, but not do anything that would break instructions
<ryanofsky>
*break previous instructions
mcey_ has joined #bitcoin-core-dev
<Sjors[m]>
So my suggestion would be "bitcoin" for everything except "bitcoind", and then change that to "bitcoin" in a later release.
<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
<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?
mcey has quit [Ping timeout: 245 seconds]
<ryanofsky>
I'm ok with sjors approach of keeping bitcoind in docs too if we want to start with that
zeropoint has joined #bitcoin-core-dev
<Sjors[m]>
cfields: #31802 does that for the release
<TheCharlatan>
cfields that would be my preference too once 31741 is merged.
<Sjors[m]>
Slower compilation?
<fanquake>
Devs should be testing and using what we are shipping to end users
<fanquake>
Install ccache
<cfields>
+1
<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
<Sjors[m]>
My machine is fast enough, I didn't even realise I forgot ccache for the first week :-)
<cfields>
And docs should generally reflect what devs see with a default build.
<fanquake>
we’re not going to flick options in Guix that no dev is testing or using locally
<ryanofsky>
I think multiprocess is already enabled in dev build preset
<Sjors[m]>
Oh yes, I meant that it's not on in cmake by default, but I don't konw about the dev preset.
<ryanofsky>
Yes I would like it to be on in cmake default too
<Sjors[m]>
But it sounds like we want it for the "default build", not just the test build?
<TheCharlatan>
yes
<Sjors[m]>
Will do
<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.
<cfields>
er, 31741 sorry.
<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
<Sjors[m]>
ok, that's fine too
<Sjors[m]>
But keep in mind that if you turn it on by default for depends, it will end up in the guix build.
<achow101>
Any other topics to discuss?
<ryanofsky>
Sjors[m] sorry did not want to imply turning it on by default in that PR
<ryanofsky>
I think I think it would be a good small followup, either in your PR or another one
<cfields>
Sjors[m]: good point. I'm not sure the question of what to ship has been hashed out yet.
<cfields>
but I guess if the docs are recommending it...?
<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
<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.
<fanquake>
Isn’t the whole point of this to ship the MP stuff though?
<fanquake>
For the mining interface?
<fanquake>
The wrapper seems unrelated
<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