romanz
rpc - listen on multiple interfaces
Right now it appears that it's only possible to listen on a single interface for the rpc server. I can specify --electrum-rpc-addr only once. I think it would be nice to be able to specify more than one interface, for example if I want to use both 127.0.0.1 and the LAN address.
I'm not sure that there is a way to bind a single socket to a subset of your network interfaces: https://stackoverflow.com/questions/12709771/how-to-bind-a-socket-to-multiple-interfaces
Does binding to all interfaces ("0.0.0.0") may work for you?
I could certainly bind to 0.0.0.0, but that's not always going to be an adequate solution for others.
It's definitely possible to listen on multiple interfaces - bitcoind has the rpcbind option which can be specified multiple times. I don't think you'd need to bind a particular socket to more than one interface, just to listen on more than one interface for incoming socket connections.
This isn't a pressing issue for me by any means, but it seems like a desirable feature. ElectrumX allows this for example, the HOST environment variable can be a comma separated list to specify multiple interfaces.
@4NobleTruths could you describe your situation a bit more?
One issue with allowing this is it could lead to very confusing configuration. Currently all configuration options read later override the options provided sooner. Allowing multiple options would merge them together. I don't think it'd be useful. Even if it was allowed, Toml format doesn't allow repeating the same key multiple times, It'd have to be and array.
We could make it an array and the late arrays would override sooner arrays. But then how do you represent an array on command line? Multiple switches would just override.
We could allow the addresses to be specified in a string using some separator (e.g. ;) That'd be at least consistent between config and arguments. But it's not very composable. But maybe the users who want it don't need composability?
@Kixunil Thank you for your attention and great accomplishment with this project. It's not a high priority request. I'm sure there are more important things you want to address. Unfortunately, some really useful things are appearing that are only easily installed as a docker network. They can't use 127.0.0.1 to reach electrs, unless maybe they are set up in a less secure --host mode. Otherwise, localhost in those networks is the OS in each container. They come out to the docker host through a 172.x.x.x/8 interface.
Then most of us also have all the usual stuff - Electrum wallet, etcetera, which use the localhost in the traditional way.
I'm sorry I don't know what composable means. An csv array I think would work - electrum_rpc_address=x.x.x.x,y.y.y.y You could just say that such setups can only be implemented through the conf file. That's where I prefer to make changes, because the alternative is in the systemd service. Once the server is set up, I doubt many use CLI to start it.
It's not a big deal, but I think for highest reliability, security and fault tolerance, different clients should be as separated as possible and never be force to use 0.0.0.0 by design, unless they really are meant to respond to the internet. I think that's why Bitcoin can rpcbind to more than one ip. Electrum and such are for financial networking; I think users of that want as much networking security and flexibility as possible, but this feature isn't a priority for me.
A comma separated list on the command line seems fine to me, or if it's too much trouble it would also be OK if specifying multiple listening interfaces is only possible via the config file. An array in the config file seems perfectly fine. Ultimately I think going with whatever is easiest from a config standpoint would be good as long as its documented.
Good point about not supporting it in CLI, putting it to config only would be easy. What do you think @romanz ? Sadly I can't promise contribution from my side anytime sooner than a few weeks. I could help with review though.
@4NobleTruths What I meant by composable is the ability to use configuration from multiple sources sanely (without ugly stringly hacks). Electrs already supports using multiple config files, which allows one to enter bitcoind auth information into one protected file and the interface configuration into readable config file for other applications to use. So I was wondering if making extra sure that multiple addresses get merged instead of overridden is useful for you. (I use merging technique in btc-rpc-proxy and it's quite nice.)
I wonder is there a reason why binding to the single address of the docker container is insufficient? If there's nothing else in that container, then 127.0.0.1 is not needed and the specific address should work.
Also I fail to see why 0.0.0.0 would be a problem inside a container that's supposed to be isolated from the Internet. Is this just "what if Docker breaks" or am I missing something?
I agree that security should be important for electrs. Keeping developer and user sanity is important as well to not lead to other kinds of problems, that's why I'm trying to understand the problem better.
Finally a disclaimer, it seems to me I may come off as the author of electrs. I'm not, @romanz is. I'm just a contributor who helped with implementing the current configuration system among other things, that's why I'm interested. :)
@Kixunil Sorry, if I misunderstood; I thought the suggestion to set 0.0.0.0 was in relation to electrs binding to all host interfaces. I am not advanced enough to be able to answer your question about merging addresses.
It's sufficient to bind to docker bridge for me for now, which is what I did, and changed other apps to find electrs there. It's a small, low-priority suggestion, which I would rather not debate. I'm grateful for your work on electrs and enabling us to use it instead of other such apps, which are either too much or too little.
I'd like to bump this, as I'm also forced to bind to 0.0.0.0 to both use my server and allow services hosted in docker to connect to it. It'd be easier to specify interface names, especially if your IP changes often for whatever reason.
