This issue is open to discuss whether to include bitcoin-node and bitcoin-gui binaries supporting an -ipcbind option in a release. This was originally intended to happen in the 29.0 release but got postponed after an irc discussion before that release. The change currently implementing it is #31802.

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:

1. Is the primary concern that the new -ipcbind option might not work well, or might cause instability?
2. Or is it that the new bitcoin-node and bitcoin-gui executables might have problems even if -ipcbind is not specified?
3. 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?
4. 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?
5. Or is the concern not about bad external outcomes but about bad internal outcomes? For example that treating features as "experimental" could lower the bar for code review.

I'd like to know what the biggest concerns are (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 #31802 and the steps we have taken to reduce technical risks of this change:

1. The change introduces two new bitcoin-node and bitcoin-gui binaries that behave the same as existing bitcoind and bitcoin-qt binaries, and even contain the same compiled objects, they are just linked differently.
2. 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 an echoipc 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.
3. 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.
4. 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.
5. To further isolate the new dependencies, no code outside of the src/ipc/ directory and libbitcoin_ipc.a library includes them or links against them.

Because #31802 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.