IPC via TCP Sockets #32802

1. 
   plebhash commented at 1:32 pm on June 24, 2025: none

   Please describe the feature you’d like to see added.

   Interprocess communication via TCP Sockets

   Is your feature related to a problem, if so please describe it.

   I’m dockerizing @Sjors ’s Stratum V2 sidecar (bitcoin-mine) such that it’s able to reach a Bitcoin Core node running on the host.

   My host is macOS, and Docker is Linux, which means they don’t have a shared kernel and their Unix socket descriptors don’t match.

   Describe the solution you’d like

   IPC over TCP sockets.

   Describe any alternatives you’ve considered

   My current workaround is to leverage socat and create a TCP bridge between host and container.

   Please leave any additional context

   No response

2. plebhash added the label Feature on Jun 24, 2025
3. 
   Sjors commented at 1:51 pm on June 24, 2025: member

   bitcoin-mine refers to the Template Provider application I wrote in https://github.com/Sjors/bitcoin/pull/48. This is not intended to be included in Bitcoin Core.

   It’s based on the bitcoin-mine demo proposed by @ryanofsky in #30437. This may or may not be included in v30, but it doesn’t really matter if this particular demo adds TCP support (though it’s probably a good idea).

   What does matter is that the -ipcbind argument of bitcoin-node gets TCP support.

4. 
   ryanofsky commented at 3:27 pm on June 24, 2025: contributor

   The reason the ipcbind option doesn’t support TCP currently is that there’s no authentication, so listening on a TCP socket would let any process on the system running as any user connect to the port, and potentially access wallets or take advantage of privileges the bitcoin process has.

   So currently:

   • ssh provides a reasonable way to forward sockets with permissions and authentication (ssh -L /tmp/local.sock:/path/to/remote.sock user@remotehost or `ssh -R /tmp/remote.sock:/path/to/local.sock user@remotehost)

   • socat provides a reasonable way to forward sockets if authentication is not important

   Looking ahead:

   • It shouldn’t be too hard to support AF_VSOCK (virtio sockets) for communication between vm host and guest processes. These should be more secure and more performant than TCP sockets.

   • It shouldn’t be too hard to add an authentication mechanism using cookies or hashed passwords and support authenticated TCP sockets, if there is a good use-case,

   • It might make sense to let the -ipcconnect option support TCP sockets even if the -ipcbind option doesn’t support them, so maybe you only need one socat process not two if forwarding over TCP.

5. bitcoin deleted a comment on Jun 25, 2025
6. 
   Sjors commented at 8:48 am on June 25, 2025: member

   Good point about the lack of authentication.

   One use case I have in mind is (something like) a BitAxe that connects directly to your node to fetch templates to solo mine on. Currently this involves running a Stratum (v1) solo mining pool, which just adds needless complexity.

   That said, as soon as you have more than one device you’re going to need pool software to divide the work between them. At that point it makes more sense to run a sidecar application on the same machine as the node, and have it listen on TCP and deal with authentication.

7. 
   plebhash commented at 8:43 pm on November 17, 2025: none

   what about encryption?

   assuming authentication is solved, would it be safe to use this outside of a controlled LAN environment?

8. 
   Sjors commented at 10:02 am on November 18, 2025: member

   RPC connections are not encrypted either and I’m not aware of any plans for changing that.

   Maybe virtio socket support would be the easiest approach for getting Docker setups to work? That might be useful for RPC too. I opened #33897 to discuss.

9. 
   plebhash commented at 12:25 pm on November 18, 2025: none

   apparently @lucasbalieiro was able to ship https://github.com/stratum-mining/sv2-apps/pull/85 without running into the Docker challenges I originally described as the motivation for IPC via TCP here… I’m yet to dive into it and figure out whether I had any blindspots when opened this issue here

   when I asked about encryption I didn’t really have the Docker setup in mind… I was just curious about potential use-cases of IPC over TCP

10. 
    Sjors commented at 1:34 pm on November 18, 2025: member

    Ok, keep us posted on what you learn.
11. 
    ryanofsky commented at 9:29 pm on November 18, 2025: contributor

    Rereading the issue, I noticed I missed the references to docker, and just posted about alternatives to TCP generally.

    As far as I know, there should be no issue sharing the IPC socket between the docker containers or between the host and a container on linux. The socket should look like normal file on the filesystem (node.sock) that can be shared with docker’s --volume / -v option. On macos I don’t think it’s possible to share the socket between a host and container, but it should be possible to do it between containers using a shared volume. If you do need to share the socket between the host and a container on mac, it should be possible but you’d need to use a tool like socat or ssh to forward the connection over TCP.

Contributors
plebhash Sjors ryanofsky

Labels
Feature