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.

Contributors
plebhash Sjors ryanofsky

Labels
Feature