Bitcoin multiprocess questions & concerns

[ryanofsky]

Originally posted by @jimhashhq in #31756

Like the multiprocess (MP) project; am in favor of the option to build extra binaries for an MP bitcoin.
Personally, would like either of the following:

• a more complete MP implementation (with wallet process RPC listener, etc.), or
• renaming of release package to something like "IPC node" only, for transparency, with a delayed libmultiprocess subtree merge #31741, hinging on the completion of MP wallet usages.

Questions follow:

1. Don't understand how adding gui to node release could happen without a the MP wallet process too?
   Thought there were two release paths either "IPC node" or "MP node, gui, & wallet," doesn't gui depend on wallet. Apologies.

2. What % complete is multiprocess?
   Release without earlier prs
   -#19460
   -#19461
   (--ipcconnect for wallet and gui) is incomplete, especially as 19460 only connects and doesn't do anything.
   Maybe too much "interface rationalization" needed to ever complete 19460?

3. IPC node release would benefit mining usages; are MP proponents committed to completing the rest of MP feature?
   Personally favor a more fully functional release, including wallet RPC listener.
   Until wallet MP usages are complete, suggest leaving libmultiprocess as separate project.
   Solutions to "cmake w/external-library" concerns provided might help to guide "cmake challenged" devs, integrators, & testers more easily through external build process.

4. Is there a plan to follow-through on related "interface rationalization?" What stands out is current degenerate behavior of node spawning a wallet with node acting as a go-between for gui <-> wallet interactions.

5. Are there any additional tests that need to be developed? In addition to one for bitcoin-core/libmultiprocess#169.

6. Doc additions: --ipcbind=N not covered in design spec or elsewhere.

7. Was expecting a MULTIPROCESS project label be created long ago for this feature?

8. Are there any unforeseen synchronization challenges adding KJ cooperative multitasking coroutines (for Cap'N Proto promise feature) to a mature Boost threaded project like bitcoin?

Outside the scope of this:

• Seems like some --disablewallet tests disappeared (or were superseded) over the years which I have not looked into, apologies. comment on #19641
• Would some sort of user guide benefit operators interested in MP deployment, preventing operator errors?

IIUI, seems like the current proposed release packaging centers around a node with an IPC listener tailored to suit mining integrations. This doesn't address interface rationalizations to allow for true/complete MP deployment, with a working wallet process, servicing RPC requests without relying on the node to act as a go-between.

[ryanofsky]

Appreciate the questions and suggestions @jimhashhq! Created this separate issue to answer them just to keep the discussion in #31756 more focused (and will also respond there).

• renaming of release package to something like "IPC node" only, for transparency

You may want to comment on bitcoin/bitcoin#30983 where various pros/cons of this approach are discussed.

• , with a delayed libmultiprocess subtree merge multiprocess: Add libmultiprocess git subtree #31741, hinging on the completion of MP wallet usages.

Idea behind merging bitcoin/bitcoin#31741 soon is to make IPC & multiprocess features easier for developers to build and test, but I'd welcome any comments on bitcoin/bitcoin#31741.

Questions follow:

1. Don't understand how adding gui to node release could happen without a the MP wallet process too?
   Thought there were two release paths either "IPC node" or "MP node, gui, & wallet," doesn't gui depend on wallet. Apologies.

This sounds like a question about bitcoin/bitcoin#10102, but currently on master when you enable building bitcoin-node and bitcoin-gui binaries they only have one new feature: an -ipcbind flag supporting a mining interface. So the wallet is not really related or affected at all. But in the current implementation of bitcoin/bitcoin#10102, enabling IPC also affects bitcoin-wallet binary as you suggest.

2. What % complete is multiprocess?

I think as infrastructure it is ready and feature complete, but there are various things we can do with the infrastructure which are in different stages of development. Some of those things are implemented in PRs like bitcoin/bitcoin#10102 and bitcoin/bitcoin#19461. Others should also be implemented like improving the capnproto interfaces and letting the wallet process communicate directly with RPC clients and the GUI without going through the node. And there are probably more things I haven't thought of.

3. IPC node release would benefit mining usages; are MP proponents committed to completing the rest of MP feature?

I'd say reasonably committed, but not sure exact purpose of this question. If the suggestion is that it would be bad to release the IPC mining feature without releasing multiprocess features like bitcoin/bitcoin#10102 and bitcoin/bitcoin#19461 at some point later then I mostly agree.

I don't think there would be any problem doing this from a user-perspective as long as there is a wrapper executable (bitcoin/bitcoin#31375) parsing the options and users do not have to care about what executable is started when the mining interface option is enabled. But from a software maintenance perspective I don't think keeping the current IPC and multiprocess code would be justified if the only thing it was used for was providing the mining interface. A lot of current IPC code should be deleted if we only wanted to keep the mining interface.

Personally favor a more fully functional release, including wallet RPC listener.
Until wallet MP usages are complete, suggest leaving libmultiprocess as separate project.
Solutions to "cmake w/external-library" concerns provided might help to guide "cmake challenged" devs, integrators, & testers more easily through external build process.

You may want to comment on bitcoin/bitcoin#31741, but I'm not sure I see major downsides to including libmultiprocess as a subtree, and making building and testing easier.

4. Is there a plan to follow-through on related "interface rationalization?" What stands out is current degenerate behavior of node spawning a wallet with node acting as a go-between for gui <-> wallet interactions.

There's no current plan for this. I don't think that behavior would be hard to change though. If you consider it a blocker, can comment on bitcoin/bitcoin#10102 or make a new issue here and I can look into it.

5. Are there any additional tests that need to be developed? In addition to one for bitcoin-core/libmultiprocess#169.

Yes, part of the reason I've procrastinated fixing those issues is that I wanted to think of a good way to write tests for them.

6. Doc additions: --ipcbind=N not covered in design spec or elsewhere.

Agree it would probably be reasonable to mention this in the design document and other places.

7. Was expecting a MULTIPROCESS project label be created long ago for this feature?

I don't use github labels and was a little reluctant to create a custom label for my own PRs. I've just been keeping my tracking issue up to date bitcoin/bitcoin#28722 and this has worked well for me. If you have a use-case for labels, would recommend opening up a quick issue bitcoin https://github.com/bitcoin/bitcoin/issues/new/ describing what you'd like to see and how it would be useful, and then maintainers or others who actually do use labels could say whether they think its a good idea or just go ahead and add the label.

8. Are there any unforeseen synchronization challenges adding KJ cooperative multitasking coroutines (for Cap'N Proto promise feature) to a mature Boost threaded project like bitcoin?

There have definitely been unforeseen bugs, but I think intended 1:1 threading model is mostly straightforward and should not present any general problems.

Outside the scope of this:

• Seems like some --disablewallet tests disappeared (or were superseded) over the years which I have not looked into, apologies. comment on #19641

Not sure about this but it would be nice to see a PR adding test coverage.

• Would some sort of user guide benefit operators interested in MP deployment, preventing operator errors?

I don't really think so. I hope most features will be implemented in a way where users don't have to care about them. I would like the main CLI user interface to be the bitcoin wrapper command implemented bitcoin/bitcoin#31375, and for the wrapper to improve over time so for example if you start the daemon first and the gui second, the the gui will automatically connect to the daemon instead of starting a conflicting one. Or if the -ipcbind feature becomes ready for use before other multiprocess features, would like the wrapper to automatically start the bitcoin-node binary when it's used instead of bitcoind.

IIUI, seems like the current proposed release packaging centers around a node with an IPC listener tailored to suit mining integrations. This doesn't address interface rationalizations to allow for true/complete MP deployment, with a working wallet process, servicing RPC requests without relying on the node to act as a go-between.

I think the bitcoin wrapper command implemented bitcoin/bitcoin#31375 can generally provide a good command line interface. The challenge with wallets serving RPC requests is that they will need to listen on their own ports so we may want to figure out some scheme (maybe using redirects) where port numbers don't have to be specified with each individual CLI RPC command. If you have thoughts on this or other things like this, would suggest opening separate issues at https://github.com/bitcoin-core/libmultiprocess/issues/new to discuss