Support for distant Bitcoind

[max302]

Hello,

The README file mentions the use of txTenna-server with a local instance of Bitcoind. In many use cases, it might be useful to use remote full nodes else where on the local network (Pi + GTN on a pole mount, full node in server room).

python-bitcoinlib's Proxy class supports this through passing init variables, so it looks like an easy fix. txTenna server also has remote node support built in, although passing transactions don't seem to use it as a proxy for propagation anyways, so that seems to be irrelevant.

Am I missing something?

I intend to fork and play around with the code, but figured I'd highlight just to get some feedback.

[remyers]

Hi @max302 - great question. I just checked in an afc488d which adds the --local flag to use a local bitcoind. Otherwise it will use a remote instance of txtenna-server. The one run by Samourai is hard coded, but this could be a variable if you want to run your own bitcoind an txtenna-server instance.

Does this answer your question?

[max302]

What confuses me is the naming of the functions I guess.

I assumed that the logical path for incoming transactions was always to be txtenna-python -> txtenna-server -> bitcoin full node. I viewed txtenna-server as a sort of middleware between the hardware interface (txtenna-python), which is why I was surprised to see many functions depend on the bitcoin.rpc.Proxy() class.

For example, handle_message() calls on a txtenna-server endpoint, which is what I expected. However, confirm_bitcoin_tx_local() calls directly on the full node through the bitcoin RPC proxy with no arguments, thus assuming a node available on localhost at default ports.

I think it's reasonable to a assume txTenna-python and txtenna-server are running on the same machine, but local presence of a full node is likely less reasonable. I'm a hardware guy, so I'm thinking about how to run this in a permanent, wired-in fashion, and the best option is probably a poled-mounted RPi running txtenna-python and txtenna-server connected to the GTN, and all full-node comms going to some other machine on the network.

Long story short the options for both the txTenna-server AND the bitcoind instances should both be configurable, kind of like how it's done in txTenna-server itself.

Like I said, I'll fork and try to write a few things to make my point clearer.

[remyers]

FYI, if you do not use the new --local flag, the default now is to use confirm_bitcoin_tx_online() which currently points to the txTennna-server run by the Samourai team at https://api.samourai.io .

If you have a full node somewhere else on your local network, it's probably easiest to run txTenna-server on the same machine as your fullnode and change txtenna.py to point to it.

On the other hand, I'd like to remove the txTenna-server dependency and just use the Python Bitcoin Library to reassemble segments into a transaction that can be pushed on the to the Bitcoin network. In that case we'd need to access a fullnode that wasn't local using bitcoind RPC calls.

[remyers]

Change 7be117b removes reference to a local txtenna-server instance and adds support for confirming transactions with thelocal instance of bitcoin using the --local flag.

[remyers]

TODO: add an argument to define which txtenna-server to use to submit transactions if --local is not used.