In the previous commit, all peers served an onion.
After this commit, taker client instances will automatically
send a config var to the jmdaemon backend that instructs
the OnionMessageChannel instance to not start an onion service,
and the handshake messages sent by these peers replace the
onion location with a placeholder string NOT-SERVING-ONION.
Directories and maker peers will not therefore to connect outbound
to them, but privmsging still happens p2p with connections from
takers to makers after the directory has communicated their
reachable .onion addresses.
This change reduces the configuration requirement for takers and
is better for their privacy and security (without sacrificing
the gain we get from having p2p connections).
The above comments re: takers also apply to ob-watcher bots.
This commit also fixes a large number of minor bugs and errors in
documentation, as well as many Python cleanups after review from
@PulpCattel. A few concrete items are:
It fixes the ob-watcher functionality to work with the new subclass
of MessageChannel (OnionMessageChannel).
It corrects the on_nick_leave trigger to make dynamic nick switching
between MessageChannels (as implemented in MessageChannelCollection)
work correctly.
It corrects the order of events in the add_peer workflow to ensure that
a handshake can always be sent so that the activation of the connection
always works.
It sets a default messaging config with onion, 2 active IRC servers and
one inactive IRC server. The onion config has 2 signet directory nodes,
so this will change to mainnet after the PR is merged to master.
# This setting is ONLY for developer regtest setups,
# running multiple bots at once. Don't alter it otherwise
regtest_count = 0,0
```
```
Here, I have deliberately omitted the several other settings in this section which will almost always be fine as default;
All of these can be left as default for most users, except the field `directory_nodes`.
see `jmclient/jmclient/configure.py` for what those defaults are, and the extensive comments explaining.
The main point is the list of **directory nodes** (the one shown here is one being run on signet, right now), which will
The list of **directory nodes** (the one shown here is one being run on signet, right now), which will
be comma separated if multiple directory nodes are configured (we expect there will be 2 or 3 as a normal situation).
be comma separated if multiple directory nodes are configured (we expect there will be 2 or 3 as a normal situation).
The `onion_serving_port` is on which port on the local machine the onion service is served.
The `onion_serving_port` is on which port on the local machine the onion service is served; you won't usually need to use it, but it mustn't conflict with some other usage (so if you have something running on port 8080, change it).
The `type` field must always be `onion` in this case, and distinguishes it from IRC message channels and others.
The `type` field must always be `onion` in this case, and distinguishes it from IRC message channels and others.
### Can/should I still run IRC message channels?
### Can/should I still run IRC message channels?
@ -50,11 +84,24 @@ In short, yes.
### Do I need to configure Tor, and if so, how?
### Do I need to configure Tor, and if so, how?
These message channels use both outbound and inbound connections to onion services (or "hidden services").
To make outbound Tor connections to other onions in the network, you will need to configure the
SOCKS5 proxy settings (so, only directory nodes may *not* need this; everyone else does).
This is identical to what we already do for IRC, except that in this case, we disallow clearnet connections.
#### Running/testing as a maker
A maker will additionally allow *inbound* connections to an onion service.
This onion service will be ephemeral, that is, it will have a different onion address every time
you restart. This should work automatically, using your existing Tor daemon (here, we are using
the same code as we use when running the `receive-payjoin` script, essentially).
#### Running/testing as other bots (taker)
A taker will not attempt to serve an onion; it will only use outbound connections, first to directory
nodes and then, as according to need, to individual makers, also.
As previously mentioned, both of these features were already in use in Joinmarket. If you never served an
As previously mentioned, both of these features - inbound and outbound, to onion, Tor connections - were already in use in Joinmarket. If you want to run/test as a maker bot, but never served an onion service before, it should work fine as long as you have the Tor service running in the background,
onion service before, it should work fine as long as you have the Tor service running in the background,
and the default control port 9051 (if not, change that value in the `joinmarket.cfg`, see above).
and the default control port 9051 (if not, change that value in the `joinmarket.cfg`, see above.
#### Why not use Lightning based onions?
#### Why not use Lightning based onions?
@ -85,7 +132,7 @@ and pay attention to the settings in `regtest_joinmarket.cfg`.)
There is no separate/special configuration for signet other than the configuration that is already needed for running
There is no separate/special configuration for signet other than the configuration that is already needed for running
Joinmarket against a signet backend (so e.g. RPC port of 38332).
Joinmarket against a signet backend (so e.g. RPC port of 38332).
Add the `[MESSAGING:onion1]` message channel section to your `joinmarket.cfg`, as listed above, including the
Add the `[MESSAGING:onion]` message channel section to your `joinmarket.cfg`, as listed above, including the
for the simplest test, remove the other `[MESSAGING:*]` sections that you have.
for the simplest test, remove the other `[MESSAGING:*]` sections that you have.
@ -101,19 +148,19 @@ who would like to help by running a directory node. You can ignore it if that do
This requires a long running bot. It should be on a server you can keep running permanently, so perhaps a VPS,
This requires a long running bot. It should be on a server you can keep running permanently, so perhaps a VPS,
but in any case, very high uptime. For reliability it also makes sense to configure to run as a systemd service.
but in any case, very high uptime. For reliability it also makes sense to configure to run as a systemd service.
A note: in this early stage, the usage of Lightning is only really network-layer stuff, and the usage of bitcoin, is none; feel free to add elements that remove any need for a backend bitcoin blockchain, but beware: future upgrades *could* mean that the directory node really does need the bitcoin backend.
A note: the most natural way to run the directory is as a Joinmarket *maker* bot, i.e. run `yg-privacyenhanced.py`, with configuration as described below. For now it will actually offer to do coinjoins - we will want to fix this in future so no coins are needed (but it can just be a trivial size).
#### Joinmarket-specific configuration
#### Joinmarket-specific configuration
Add `hidden_service_dir` to your `[MESSAGING:onion1]` with a directory accessible to your user. You may want to lock this down
Add `hidden_service_dir` to your `[MESSAGING:onion]` with a directory accessible to your user. You may want to lock this down
a bit!
a bit!
The point to understand is: Joinmarket's `jmbase.JMHiddenService` will, if configured with a non-empty `hidden_service_dir`
The point to understand is: Joinmarket's `jmbase.JMHiddenService` will, if configured with a non-empty `hidden_service_dir`
field, actually start an *independent* instance of Tor specifically for serving this, under the current user.
field, actually start an *independent* instance of Tor specifically for serving this, under the current user.
(our tor interface library `txtorcon` needs read access to the Tor HS dir, so it's troublesome to do this another way).
(our Tor interface library `txtorcon` needs read access to the Tor HS dir, so it's troublesome to do this another way).
##### Question: How to configure the `directory-nodes` list in our `joinmarket.cfg` for this directory node bot?
##### Question: How to configure the `directory-nodes` list in our `joinmarket.cfg` for this directory node bot?
Answer: **you must only enter your own node in this list!** (otherwise you may find your bot infinitely rebroadcasting messages).
Answer: **you must only enter your own node in this list!**. This way your bot will recognize that it is a directory node and it avoids weird edge case behaviour (so don't add *other* known directory nodes; you won't be talking to them).
#### Suggested setup of a service:
#### Suggested setup of a service:
@ -143,7 +190,7 @@ WantedBy=multi-user.target
```
```
This is deliberately a super-basic setup (see above). Don't forget to setup your `bitcoin.conf` as usual,
This is deliberately a super-basic setup (see above). Don't forget to setup your `bitcoin.conf` as usual,
for the bitcoin user, and make it match (specifically in terms of RPC) what you set up for Lightning below.
for the bitcoin user, and make it match (specifically in terms of RPC) what you set up for Joinmarket below.
2.
2.
@ -167,7 +214,6 @@ To state the obvious, the idea here is that this second service will run the JM
to ensure they start up in the correct order.
to ensure they start up in the correct order.
Re: password echo, obviously this kind of password entry is bad;
Re: password echo, obviously this kind of password entry is bad;
for now we needn't worry as these nodes don't need to carry any real coins (and it's better they don't!).
for now we needn't worry as these nodes don't need to carry significant coins (and it's much better they don't!).
Later we may need to change that (though of course you can use standard measures to protect the box).
TODO: add some material on network hardening/firewalls here, I guess.
TODO: add some material on network hardening/firewalls here, I guess.
Adam Gibson
4 years ago