`teosd` doesn't refuse to run when `bitcoind` is not running on the same network

[mariocynicys]

For instance, If bitcoind is running on regtest, and we set teosd to run on mainnet. It works fine, which isn't the expected behavior.

This is assuming we got bitcoind port right and successfully connected to it (by setting the port in either bitcoin or teos configs or both).

[sr-gi]

Cannot reproduce. Are you hardcoding the btcrcpport?

> bitcoind
[...]
2022-08-31T12:32:25Z Config file arg: debug="1"
2022-08-31T12:32:25Z Config file arg: dnsseed="0"
2022-08-31T12:32:25Z Config file arg: regtest="1"
2022-08-31T12:32:25Z Config file arg: rpcpassword=****
2022-08-31T12:32:25Z Config file arg: rpcuser=****
2022-08-31T12:32:25Z Config file arg: server="1"
2022-08-31T12:32:25Z Config file arg: txindex="1"

> teosd --btcnetwork=bitcoin
2022-08-31T12:33:35.968Z INFO [teosd] Loading configuration from file
2022-08-31T12:33:35.969Z INFO [teosd] tower_id: 02cf1bb8e9b3abcc4ed76bf8944d3590067feb8ceefe15d8fa5fc8853bd88cd60e
2022-08-31T12:33:35.970Z ERROR [teosd] Failed to connect to bitcoind. Error: Connection refused (os error 61)

> teosd --btcnetwork=regtest
2022-08-31T12:33:49.827Z INFO [teosd] Loading configuration from file
2022-08-31T12:33:49.828Z INFO [teosd] tower_id: 0205b0abf5ce8158ab991191d55f9690b62eb2cdfdd9ef714edfd3a339e8cec32a
2022-08-31T12:33:49.832Z INFO [teosd] Last known block: 1697d4843256e60cf989697ac87037d7179900a2096af76f700cd2f42b74f006
2022-08-31T12:33:49.841Z INFO [teosd] Bootstrapping from backed up data
2022-08-31T12:33:49.842Z INFO [teosd] Bootstrap completed. Turning on interfaces
2022-08-31T12:33:49.844Z INFO [teosd] Tower ready

[mariocynicys]

@sr-gi yup, I have btc port set in all my configs. that's what it wasn't failing for me.

[mariocynicys]

There is that rpc that does query bitcoind for network info and tells which network bitcoind is running on. "getblockchaininfo".

[sr-gi]

Umm, I guess there's a discussion to be started here regarding the network options and the default ports.

The --network option is basically syntactic sugar for setting the proper ports. ATM, if no port is provided and a network is provided, then the default port for that network is picked:

https://github.com/talaia-labs/rust-teos/blob/master/teos/src/config.rs#L218-L225

This basically allows you to run in any network as long as whatever rpc host and port you provide match whatever bitcoind is set up to run with. We could add an additional restriction to this, by making network a mandatory option (it is not at the moment) and only allowing the daemon to run only if all match. However, I'm pretty certain the way it is right now matches both bitcoind and lightningd (CoreLN daemon)

[mariocynicys]

We can use the network option to set btc port (if it's not already set) for convenience. But network is an option by it self that needs to match the backend to be able to poll blocks. I don't see this contradicting with having default values for network and btc port though.

This is lightningd's logs when it's config states that the network is bitcoin but bitcoind running on regtest:

2022-08-31T13:09:47.445Z DEBUG   plugin-manager: started(2089) /usr/bin/../libexec/c-lightning/plugins/autoclean
...
2022-08-31T13:09:47.787Z DEBUG   connectd: REPLY WIRE_CONNECTD_INIT_REPLY with 0 fds
2022-08-31T13:09:47.787Z DEBUG   connectd: connectd_init_done
2022-08-31T13:09:47.805Z INFO    plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
2022-08-31T13:09:47.805Z DEBUG   lightningd: All Bitcoin plugin commands registered
Wrong network! Our Bitcoin backend is running on 'regtest', but we expect 'main'.

And exits with an error.

[sr-gi]

Well, that's actually the same behavior we have as long as the port is not set.

I was testing what happens if there is a contradiction between network and port (for instance we set network to regtest but port to 8332) and the network flag is actually ignored

2022-08-31T13:38:59.658Z **BROKEN** plugin-bcli: \nCould not connect to bitcoind using bitcoin-cli. Is bitcoind running?\n\nMake sure you have bitcoind running and that bitcoin-cli is able to connect to bitcoind.\n\nYou can verify that your Bitcoin Core installation is ready for use by running:\n\n    $ bitcoin-cli -regtest -rpcport=8332 echo 'hello world'\n
2022-08-31T13:38:59.659Z INFO    plugin-bcli: Killing plugin: exited before we sent init

That's because lightningd actually forwards that command to bitcoind, which does ignore the network if the rpcport is set:

> bitcoin-cli -regtest -rpcport=8332 echo 'hello world'\n

error: timeout on transient error: Could not connect to the server 127.0.0.1:8332

Make sure the bitcoind server is running and that you are connecting to the correct RPC port.

[sr-gi]

But actually, if this is set up the other way around (network is wrong but port is right), then lightningd does check the getblockchaininfo result and compare the chain field:

> lightningd --network=bitcoin --bitcoin-rpcport=18443
[...]
Wrong network! Our Bitcoin backend is running on 'regtest', but we expect 'main'.

So I guess we should decide whether we want to mimic bitcoind's or lightningd's behavior.

[mariocynicys]

I mean, generally, when the network is wrong (on a successful connection to bitcoind) we should refuse to run. This would happen if:

• We let bitcoind run on port X & network A, but teosd tries to connect to port X expecting network B. (port X can be any port, even the default port for other networks: have the network be regtest and tell bitcoind to run on 8332 which is the default port for mainnet)

But isn't covered in this issue when:

• We let bitcoind run on port X & network A, but teosd tried to connect to port Y & network A. (with port Y being the default port for network A, and X isn't)

I am ignoring the case when teosd doesn't actually connect to bitcoind because the user didn't specify the port correctly. I am assuming the connection was successful, when we connect, we should check for the network we are connected to.

[sr-gi]

Ok, agreed.