Not possible to have a non persistent not announced .onion address if the node is Not on an internal network

[gabridome]

Issue and Steps to Reproduce

If the node is NOT on an internal network and doesn't want to announce its .onion address,
according to:

# lightningd --help
--bind-addr <arg>                    Set an IP address (v4 or v6) to listen on, but not announce

and according to tor.md in doc directory,
the --bind-address=autotor:127.0.0.1:9051 option should be used to bind the service to a non persistent .onion address without announcing it.

This behaviour used to work and the generated .onion address resulted in the output of the lightning-cli getinfocommand.

as v0.6.2, this doesn't work anymore.

starting with:

lightningd --proxy=127.0.0.1:9050 --bind-addr=autotor:127.0.0.1:9051 --addr=127.0.0.1:9738 --network=bitcoin

You get:

$ lightning-cli getinfo
{
  "id": "02c4fec754506ea170712588600bf23f11fa123aa6b0eaf1e3617c1e6a6cd02848", 
  "alias": "LIGHTNINGARTIST", 
  "color": "02c4fe", 
  "address": [ # <<<<<<<<<<<<<<<<<<< empty!
  ], 
  "binding": [
    {
      "type": "ipv4", 
      "address": "127.0.0.1", 
      "port": 9738
    }
  ], 
  "version": "v0.6.2", 
  "blockheight": 554055, 
  "network": "bitcoin", 
  "msatoshi_fees_collected": 0
}

If an address has been generated, is not available anywhere.
If the intent is to get rid of the --bind-addr option in the case the node is not on an internal network, some correction is necessary to the documentation.

[Saibato]

hello @gabridome can confirm your issue.
i have a now working version in my branch at bindtor Saibato@c02929f
but i have to do more tests as we dont want to leak ;-) our 🖤
if all is fine i push the PR

[gabridome]

Great!
It create a strange behaviour in which nodes inside a network could hide their non persistent .onion address, while exposed servers could not.

[Saibato]

Hello @gabridome i now pushed the PR Saibato@d5d9936
👍

[Saibato]

Great!
It create a strange behaviour in which nodes inside a network could hide their non persistent .onion address, while exposed servers could not.

Thanks this is also addressed now

Please also note some other unrelated fact, that the assumption "non persistent" is only true if you always also restart tor.
autotor: as now implemented generates random bindings on every start of LN
but as long as tor is running and the cruft is not rebooted or tor restarted the temp .onions still pesist.
So maybe this can be more explicit documented?

[cdecker]

Fixed by #2192

[gabridome]

Please also note some other unrelated fact, that the assumption "non persistent" is only true if you always also restart tor.
autotor: as now implemented generates random bindings on every start of LN
but as long as tor is running and the cruft is not rebooted or tor restarted the temp .onions still pesist.
So maybe this can be more explicit documented?

Concept ACK.

The document already states: "To provide the node a non-persistent .onion address is necessary to access the Tor auto service. These types of addresses change each time the Tor service is restarted."
We could add something like "(autotor: generates random bindings on every start of LN. If the service is not restarted the .onion address persists)"