I want to reopen topic of including multiprocess binaries in 29.0. I’m fine with any decision on this issue, but I was rereading the previous irc discussion and it struck me as abstract and process-oriented, detached from practical reality, and likely based on misperceptions of the actual change being discussed.
I think it would be helpful if people who had concerns about including bitcoin-node
and bitcoin-gui
binaries in a release (assuming they are not in bin/
and not on the PATH
, see #31679) could clarify what their concerns are in practical terms. For example:
- Is the primary concern that the new
-ipcbind
option might not work well, or might cause instability? - Or is it that the new
bitcoin-node
andbitcoin-gui
executables might have problems even if-ipcbind
is not specified? - Or is it a signalling issue, like if we released an experimental feature, it could cause backlash later if the feature had to be changed or removed?
- Or is adding opt-in, experimental features just always bad? Is it bad to add any new feature in a disabled state and label it as new and less tested and likely to change, and ask users to help test and improve it?
- Or is the concern not about bad external outcomes but about bad internal outcomes? Like including a feature in binary releases that is not enabled by default in cmake would set a bad precedent?
I’d like to know more about specific concerns (from @darosior @fanquake @theuni @sipa @stickies-v or anyone else) not to have a debate about them but to know what I / we should be working on and prioritizing to address them. I would appreciate concrete input here and would like to know what, specifically, people are collectively or individually worried about.
For clarity, I do want to describe the actual release change being proposed (in 081bfa7f1a7dc130d020bc6b1225680f4eacb4bf from #31802) and the steps we have taken to reduce technical risks of this change:
- The change introduces two new
bitcoin-node
andbitcoin-gui
binaries that behave the same as existingbitcoind
andbitcoin-qt
binaries, and even contain the same compiled objects, they are just linked differently. - The new binaries have only two differences in behavior from existing binaries: (1) They introduce a new
-ipcbind
option disabled by default, that, if specified, will listen on a unix socket and expose a small mining interface. And (2) they they have anechoipc
RPC method implementation that will test spawning and communicating with a subprocess. There are no other differences. The new binaries behave exactly the same as the existing ones unless you are actively using new features. #10102 would create bigger differences but #10102 is not targeted for 29.0. - The new mining interface has smallest possible implementation, sharing as much code as possible with RPC’s, and exposing as many features as it is possible to expose with RPC’s.
- The new binaries have two new dependencies: capnproto and libmultiprocess. Since there is risk in adding new dependencies, we are creating separate binaries specifically so nobody who does not actually want these dependencies will have them.
- To further isolate the new dependencies, no code outside of the
src/ipc/
directory andlibbitcoin_ipc.a
library includes them or links against them.
Because 081bfa7f1a7dc130d020bc6b1225680f4eacb4bf adds a feature that is isolated in the ways described above and disabled by default, it seems very low risk to me. It actually seems less risky than the average PR.
This issue is part of the process separation project.