search

ez-org / eznode

✨ A simple pruning-friendly setup for a personal bitcoin full node
https://ezno.de
MIT License
55 stars 7 forks source link

Using existing node automatically #8

Open Kixunil opened 3 years ago

Kixunil commented 3 years ago

Idea mentioned in https://github.com/janoside/btc-rpc-explorer/pull/279#issuecomment-808699687

TL;DR: scroll down to "The simplest client-side implementation..."

Currently I solve this in my repository by simply placing proper configuration files in standard location and then reading them from other apps. This is still sub-optimal, so I intend to use interface files. I hope to refactor it in the following months.

The general idea is that we would standardize these locations:

Where $INTERFACE refers to interface name. In case of Bitcoin, we would have these interfaces:

$NETWORK refers to mainnet|testnet|regtest|signet. We can have more permission granularity in the future.

There's obligatory _default file in the interfaces directory. This can be used in case the consumer doesn't want to mess with handling multiple services.

The simplest client-side implementation is to just try to read and parse the files in this order:

  1. $XDG_CONFIG_HOME/interfaces/bitcoin-rpc-public-$NETWORK/_default
  2. ~/.config/interfaces/bitcoin-rpc-public-$NETWORK/_default (if XDG_CONFIG_HOME is not set)
  3. /etc/interfaces/bitcoin-rpc-public-$NETWORK/_default

When one of them succeeds, break the loop and use it.

The contents of the file should be:

_spec_vesion = "1.0"
_iface_name = "bitcoin-rpc-public-mainnet"
# This is not bitcoind version but RPC and spec version
_iface_version = "1.0"
_impl_name = "bitcoind"

port = 8332
# user:pasword,
auth_token = "public:public"
# Alternatively:
# cookie_file = "/var/run/bitcoin-mainnet/cookie"
shesek commented 3 years ago

eznode runs entirely inside the docker container, without a pre-setup script that runs directly on the host. This makes cross-platform compatibility straightforward, and enables the single-command docker run setup.

This also means that eznode doesn't have full filesystem access to the host, and can't look up the config file in its expected locations. The user would have to explicitly mount it (with e.g. -v ~/.config/interfaces/bitcoin-rpc-public-mainnet/_default:/etc/interfaces/bitcoin-rpc-public-mainnet/_default), as well as mount the bitcoind data dir (if cookie auth is used), which makes it not so much automatic anymore. :<

The rpc hostname is also different, it would be 127.0.0.1 on the host but should be host.docker.internal in the container (points to the host's IP address in docker's virtual network). Your example config didn't include the host, but I assume that it could, which may be problematic? The user will also have to mount the bitcoind data dir into the same location used on the host (and configured in _default), which feels a bit unnatural in a docker env (and may potentially conflict with an existing directory, although the chances for this seem slim).

The setup is already pretty straightforward if cookie auth is used and the RPC server is listening on the default port, just a matter of mounting the bitcoind data dir (e.g. -v /home/shesek/.bitcoin:/bitcoin). But I can definitely see this being useful when this isn't the case and the port/credentials needs to be explicit. How would you go doing this under a docker environment?

Kixunil commented 3 years ago

without a pre-setup script that runs directly on the host

Would it make sense to add a very small, simple setup script for those who want to configure the internal node? It shouldn't be too hard to make it multi-platform.

Your example config didn't include the host, but I assume that it could, which may be problematic?

127.0.0.1 is assumed as the interface files are designed strictly for same-machine use case. (Can be tunneled if needed). Setup script is free to transparently map it to whatever is needed.

The user will also have to mount the bitcoind data dir into the same location used on the host (and configured in _default), which feels a bit unnatural in a docker env (and may potentially conflict with an existing directory, although the chances for this seem slim).

Why would it be required? Simple setup script would read the file and mount the appropriate directories wherever needed by the docker containers.

The setup is already pretty straightforward

I personally don't consider anything that requires manual configuration of ports and paths "straightforward". If all software was like this computers would be used by maybe five nerds and never be mainstream. I believe we as bitcoiners need to do it much better than this and bring the experience as close to out-of-the-box as possible. This is why I'm trying to come up with some reasonable standard that we all could follow in order to enable great UX.

Or did I misunderstand and eznode is not meant to be used by wider population?