Raspiblitz: Activate TOR Network on Setup

[drunkenclam]

Most Raspiblitz users are running their node from home, which makes them prone to privacy and security failures.

When setting up a new Raspiblitz, it should default to run only on TOR network. Clearnet should only be possible if the user wants to actively opt-in to advertise his node IP.

Advantages:

• more private, because the node IP isn't advertised
• more secure, because people can't see the BTC value connected to an advertised IP address
• more comfortable for users with dynamic IPs, as they don't have to handle IP changes and port forwardings
• help growing the LN network on TOR

Disadvantages:

• a node behind TOR won't probably route as much payments as a node available on clearnet
• ?

More info: https://github.com/lightningnetwork/lnd/blob/master/docs/configuring_tor.md

[openoms]

I agree with Tor on by default. It also helps with port forward issues.

Would go as far as experimenting with running a Tor relay node as well to strengthen the anonymous side of the network. Would help a lot with Initial Block Download through Tor.

See as example: https://github.com/seth586/guides/blob/master/FreeNAS/extras.md#tor-relay-node

Guide for Debian/Ubuntu: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DebianUbuntu

[RolfHodl]

Go for TOR as default! Great suggestion.

[rootzoll]

Not sure with TOR as a forced default - I like to let the user start with the mininum and then add to it by option. If TOR is a forced default, then there is no way for a user to start with the RaspiBlitz without TOR/hiddenService.

Let me paint a dramatic picture: Think of a country where its punishable by law to run TOR. Every outed RaspiBlitz user could been accused of having run TOR/hiddenService at least once, just because of the use of RaspiBlitz.

Or maybe a more paranoid picture: Someone who belives that TOR is run/subverted by a gov agency and is a honey pot would be forced joined.

BUT I think TOR on or off can be a OPTION DURING THE SETUP and so running TOR can be the first/default option here to foster its use. I think that could be the best compromise here.

[openoms]

BUT I think TOR on or off can be a OPTION DURING THE SETUP and so running TOR can be the first/default option here to foster its use. I think that could be the best compromise here.

💯% agree, yes can keep clearnet as the default, but give the option during the initial setup to have everything on Tor from the very start. This way the user's IP address and LN node public key does not get associated at all. That will be a huge improvement in privacy.

[drunkenclam]

I'd still recommend to default to TOR during initial setup with the user being able to opt-out of TOR if she wants to do so. Maybe a short explainer why to run with or without TOR.

IMHO if a user don't know what to pick here, the privacy risk by exposing the IP and the funds tied to it is far more severe than running TOR (and afaik only exit nodes had been problematic, which we are not using).

[openoms]

An argument for clearnet as the default is that the Raspiblitz is also for people who are completely new to the space and just want to try out having a full node. They might feel being forced into participating in Tor as well which is again another thing to digest and accept. Might repel some people and decrease adoption (not even going as far the potential legal /trust issues mentioned by @rootzoll).

Regarding the funds I would not suggest anyone keeping significant amounts on a "cheapest as possible" Raspberry Pi node so the "tainting" is minimal. Also I think running the bitcoin software would probably flag one up less than running Tor, but this can change and is very different between jurisdictions and threat models.

As a more advanced/paranoid user or running on an alternative platform one would build their own SD card anyway. In that we could make an option to install and activate Tor already before the first reboot.

In that case by building their own SD card one could have the option to have Tor on by default and others could choose to opt-in during the initial setup.

[openoms]

Made a branch where introduced a third parameter Tor to build the SD. When used will download only Bitcoin and Lightning and the first connections of bitcoind and LND will be through Tor.
Tor is installed after the HDD is mounted, but before bitcoind starts for the first time (or presync).

Command to test building the SD card (https://github.com/rootzoll/raspiblitz#build-the-sd-card-image):
wget https://raw.githubusercontent.com/openoms/raspiblitz/Tor_by_default/build_sdcard.sh && sudo bash build_sdcard.sh Tor_by_default openoms Tor

[openoms]

User reported bug in Telegram channel:
after updating (from 1.1 to 1.2) it seems that my bitcoin core node is stuck on block 577602 whereas we are now on (according to blockstream.info) 577661, as such it seems to be (i think?) preventing LND from starting

looking at the debug log for bitcoind in /home/bitcoin/.bitcoin/debug.log it seems to be related to tor. All the messages are things like:

2019-05-25T16:52:45Z Cannot create socket for toguvy5upyuctudx.onion:8333: unsupported network
2019-05-25T16:52:45Z Cannot create socket for ndndword5lpb7eex.onion:8333: unsupported network
2019-05-25T16:52:46Z Cannot create socket for 6m2iqgnqjxh7ulyk.onion:8333: unsupported network
2019-05-25T16:52:46Z Cannot create socket for 5tuxetn7tar3q5kp.onion:8333: unsupported network

sudo systemctl restart tor

command did not work: Failed to restart tor.service: Unit tor.service not found

The user was updating a node which had Tor on before.

Could replicate the error:
_bootstrap.provision.sh attempts to install Tor if restoring a HDD previously run behind Tor.

# TOR
if [ "${runBehindTor}" = "on" ]; then
    echo "Provisioning TOR - run config script" >> ${logFile}
    sudo sed -i "s/^message=.*/message='Setup TOR (takes time)'/g" ${infoFile}
    sudo /home/admin/config.scripts/internet.tor.sh on >> ${logFile} 2>&1
else 
    echo "Provisioning TOR - keep default" >> ${logFile}
fi

The sudo /home/admin/config.scripts/internet.tor.sh on fails beacuse the HDD is not mounted yet, the service cannot be created.

Solution:

proceed as if SD was built with Tor parameter.
Introducing TorBydefault=on to /home/admin/raspiblitz.info and install Tor after HDD is mounted in 40addHDD.sh

[openoms]

PR incoming with this one after I have done a couple of test builds.

[drunkenclam]

LN Tor usage getting more attention lately:

https://twitter.com/n1ckler/status/1133671925299982337

https://twitter.com/BtcpayServer/status/1131361209947570176

[rootzoll]

OK implemented for v1.3 release .. needs testing if working within setup process.

[openoms]

I must admit I had trouble with my implementation so will be excited to try a working one!

[rootzoll]

First test during setup shows that TOR gets installed and bitcoin syncs on it ... but bitcoin seems quite slow on catching up on sync when running behind TOR. Will see if it will catchup over night.

LND configuration looks correct for TOR after setup. Showing no URIs yet ... will wait after it has finished initial scan.

[openoms]

I have just finished testing an SSD with an Odroid XU4. Initial Block Download took ~3 days with some Internet/router troubles one night. Will try syncing on Tor now.

If syncing behind Tor (I presume) depends more on the network speed rather than processing power, running a Tor relay should be considered to strengthen the network.

It only takes as much as modifying the configuration file /etc/tor/torrc:

#change the nickname "myNiceRelay" to a name that you like 
Nickname myNiceRelay 
ORPort 443 
ExitRelay 0 
SocksPort 0
ControlSocket 0 
# Change the email address bellow and be aware that it will be published 
ContactInfo tor-operator@your-emailaddress-domain

Could be activated from the service menu after initial sync. What do you think @rootzoll ?

[rootzoll]

@openoms about activating TOR as relay node I added to this to a later issue here: #659

I am considering if the user chooses to activate TOR on setup to just apply this to the Lightning Node first (so that bitcoind is not getting that slow on ctachup syncing) and then (once full synced) you can switch also your bitcoind behind TOR ... not sure if practical possible, but from a theoretical view it should be OK as long as you dont associate your Lightning NodeID with your IP. Any concerns with that?

[rootzoll]

Catchup of bitcoind behind TOR is slow but seems to work. Will test a bit longer.

[openoms]

I am considering if the user chooses to activate TOR on setup to just apply this to the Lightning Node first (so that bitcoind is not getting that slow on ctachup syncing) and then (once full synced) you can switch also your bitcoind behind TOR ... not sure if practical possible, but from a theoretical view it should be OK as long as you dont associate your Lightning NodeID with your IP. Any concerns with that?

I agree that the most important option is to not advertise the IP of the new Lightning Node being set up, but that is an option already if port forwarding is simply not set up for 9735.
The IP only reaches the network together with the public key if port forwarding 9735 is active. In the case when the node is behind a firewall the public key is only advertised on the network when Tor is switched on. Because of this I don`t think it would worth to work on decoupling the Tor settings of bitcoind and lnd.

If someone wants to hide the fact that he is using Bitcoin and LN, Tor should be switched on for both before the Initial Sync knowing that it will affect the performance.

[drunkenclam]

Yep, that's probably the best choice: Just let the user decide if he wants to use clearnet for faster initial sync with less privacy. When finished, switch back to everything over tor.

Thanks for implementing this, unfortunately I don't have time for testing currently...

[openoms]

I have just finished testing an SSD with an Odroid XU4. Initial Block Download took ~3 days with some Internet/router troubles one night. Will try syncing on Tor now.

Started the IBD behind Tor last last night with the same config. ~20% after 10 hours. Expecting to finish roughly the same within 2-3 days. Will update this comment as it goes.

[rootzoll]

TODO: Info that torrent download is not done thru TOR (advise to copy)
TODO: Test re-rorrent download when TOR is on

[openoms]

I have just finished testing an SSD with an Odroid XU4. Initial Block Download took ~3 days with some Internet/router troubles one night. Will try syncing on Tor now.

Started the IBD behind Tor last last night with the same config. ~20% after 10 hours. Expecting to finish roughly the same within 2-3 days. Will update this comment as it goes.

This node of mine got inaccessible the second time now. First I needed to do a hard restart (pulling the plug) as it seemed to freeze and on restart it started to sync the blockchain again from 0%. Now it is again lost connection, but I am away so cannot look into it for a couple of days.

Issue: the 00raspiblitz.sh is too radical deleting all the blockchaindata in the case when there is a restart during IBD.

UPDATE: the XU4 SBC was in an off-state. Froze or failed to to power the SSD (Samsung EVO 860 rated to 1.2A). Anyway it does not seem to be problem related to the Tor network.

[rootzoll]

TODO: Test on RP3 was soo slow I will testest on a RP4.

@openoms there might even be faster way todo this I wil test on speed now - please let me know if you see any "danger" there:

• Init RaspiBlitz while on public IP (syncing Blockchain and creating a LND wallet)
• Once everything is running - switch on TOR
• Then go into new REPAIR menu and RESET LND and create a new wallet
• Now let this new wallet scan the blockchain and you should be good.

[rootzoll]

OK test showed - that doing the procedure decribed above was possible in around 2-3 hours.

Pro: Then creating new LND wallet (including node id) behind activated TOR after raspiBlitz was setup once - that node id is not associated with the users public IP.

Contra: Because the RaspiBlitz was online with Bitcoin Fullnode and old Lightning NodeID the user at least once identified thru public IP as a possible Node runner. If you are in a political environment where this alone is a problem and makes you a target, that could be a danger.

Consclusion so far: I will test activating TOR already during setup one more time. In the infoscreen when people during setup choose publicIP or TOR I may add a note that there is a faster way if you dont have the need to be total paranoid. And maybe someone can later on optimize running the setup behind TOR. Not optimal - but maybe a start.

[openoms]

TODO: Test on RP3 was soo slow I will testest on a RP4.

Do you think the RPi3 was significantly slower finishing the blockchain sync after the torrent download through Tor vs. clearnet?

OK test showed - that doing the procedure decribed above was possible in around 2-3 hours.

So it takes 2-3 hours on a RPi3 to install Tor and create a new LN wallet after everything was synced already?
Need to test this on the RPi4.

Init RaspiBlitz while on public IP (syncing Blockchain and creating a LND wallet)
Once everything is running - switch on TOR
Then go into new REPAIR menu and RESET LND and create a new wallet
Now let this new wallet scan the blockchain and you should be good.

I agree that the method described is sufficient to avoid advertising the users public IP tied to the Lightning node pubkey although the UX is far from ideal. One should not sync the first LN node just to throw it away later.
I think running a LN node on clearnet at home should be discouraged, it is like continuously disclosing to the ISP how much bitcoin one has in their Lightning node, especially now we are getting to more robust hardware where there will be no limit of 30-40 channels. Tor should be the default for the LN node for personal safety unless there is some jurisdictional concern.

Just started testing Initial Block Download behind Tor using with RPi4 and SSD.

[rootzoll]

Second try LND sync stopped syncing at 99.89% .. something is not correct yet when I select sync behind TOR in setup. I think I keep it v1.3 for now for people to test and bugfix. But if I cannot get it to run on my testmachines I will prob remove TOR selection during Setup for this comming version.

[openoms]

My node has finished syncing in ~80 hours: https://twitter.com/openoms/status/1147393450171674624?s=19

There is a bug causing bitcoind advertising it's public IP instead of .onion address. I haven't got the port 8333 forwarded so still only connected to Tor peers. Need to look up if it's only a problem with the display script.

[openoms]

Another IBD behind Tor by @bavarianledger in 96.5 hours
https://twitter.com/bavarianledger/status/1147526822617407489

[fluidvoice]

When my v1.3 VirtualBox node was synced and running OK, I then turned on Tor and it subsequently hit the same "unsupported network" errors and LND stopping as @openoms reported here: https://github.com/rootzoll/raspiblitz/issues/592#issuecomment-495934905

[coinicarus]

i am using the image for virtual box

this issue began after enabling tor.

---

[fluidvoice]

i am using the image for virtual box
this issue began after enabling tor.

do you see this?...

admin@BusterBlitz:~$ sudo grep unsupported /mnt/hdd/bitcoin/debug.log
2019-07-14T21:37:45Z Cannot create socket for fno4aakpl6sg6y47.onion:8333: unsupported network
2019-07-14T21:37:45Z Cannot create socket for toguvy5upyuctudx.onion:8333: unsupported network
2019-07-14T21:37:46Z Cannot create socket for ndndword5lpb7eex.onion:8333: unsupported network
2019-07-14T21:37:46Z Cannot create socket for 6m2iqgnqjxh7ulyk.onion:8333: unsupported network

[coinicarus]

I confirm its the same issue.

[fluidvoice]

I confirm its the same issue.

When my v1.3 VirtualBox node was synced and running OK, I then turned on Tor and it subsequently hit the same "unsupported network" errors and LND stopping as @openoms reported here: #592 (comment)

This could be due to running NAT in the VM network config. I was getting a local IP of 10.0.x.x which is not routable on my LAN. This seems to make sense the error "unsupported network" then. I just changed the VM network config to "Bridged" and now I'm getting an IP of 192.168.x.x which is routable as it's the same as my host-PC's address. I turned off Tor and LND is starting again. Now I will attempt to turn Tor back on in Bridged-IP mode and see if the problem is still there.
[edit]: no difference. The same error persists in bridged-IP mode.

[coinicarus]

powered down the vm, i changed my config to use bridged,rebooted same issue persisted,
restarted went into the main menu went into repair options and did the RESET LND, issue persisted.
After restart, i then did the RESET HDD, same issue persists.

[openoms]

@fluidvoice and @coinicarus we need to look into what fails in the Tor install.
For now you should be able to solve this temporarily by switching of Tor in bitcoin.conf.
I think we should keep this discussion about the VM away from the main repo and be in a specific topic so I opened an issue at my repo to discuss further.
Please continue there about experimentation with Tor in the VM build:
https://github.com/openoms/raspiblitz/issues/54

[coinicarus]

I dumped some logs out to https://termbin.com/n8fm
I hope something is helpful in there :) @openoms

in which directory is the bitcoin.conf file? i have tried the the following:
/etc
/home/bitcoin/.bitcoin
/mnt/hdd/bitcoin
/etc/systemd/system/

[fluidvoice]

@fluidvoice and @coinicarus we need to look into what fails in the Tor install.
For now you should be able to solve this temporarily by switching of Tor in bitcoin.conf.
I think we should keep this discussion about the VM away from the main repo and be in a specific topic so I opened an issue at my repo to discuss further.
Please continue there about experimentation with Tor in the VM build:
openoms#54

OK. @openoms question: Have you tested this lately on RPi?... turning Tor on later, after initial install and sync?

[fluidvoice]

I dumped some logs out to https://termbin.com/n8fm
I hope something is helpful in there :) @openoms

in which directory is the bitcoin.conf file? i have tried the the following:
/etc
/home/bitcoin/.bitcoin
/mnt/hdd/bitcoin
/etc/systemd/system/

see issue moved here: https://github.com/openoms/raspiblitz/issues/54#issuecomment-511593577

[woeisme]

Hey all, I've recently set up a RPI 4 (using RC3.1) node and now I'm noticing LND hangs with this message:
8 RESTARTS DETECTED - LND might be in a error loop Jul 22 04:08:46 XXXX lnd[28662]: dial tcp 127.0.0.1:9050: connect: connection refused Jul 22 04:09:46 XXXX lnd[32615]: dial tcp 127.0.0.1:9050: connect: connection refused
whenever Tor service is enabled. Additionally enabling / disabling Tor service from the main menu will add a entry to /etc/apt/sources.list (it should probably be created under /etc/apt/sources.list.d/ instead) each time, which will eventually start complaining to the user about multiple duplicate entries.

debug log can be found here:

[openoms]

We probably need to change the Tor repo to buster from stretch in line 60-61 of https://github.com/rootzoll/raspiblitz/blob/master/home.admin/config.scripts/internet.tor.sh.
Could edit it manually with:
sudo nano /home/admin/config.scripts/internet.tor.sh
uninstall: /home/admin/config.scripts/internet.tor.sh off
reinstall: /home/admin/config.scripts/internet.tor.sh on

Also check your if your torrc file is correct with:
sudo nano /etc/tor/torrc
It should have:

### See 'man tor', or https://www.torproject.org/docs/tor-manual.html

DataDirectory /mnt/hdd/tor/sys
PidFile /mnt/hdd/tor/sys/tor.pid

SafeLogging 0
Log notice stdout
Log notice file /mnt/hdd/tor/notice.log
Log info file /mnt/hdd/tor/info.log

RunAsDaemon 1
User bitcoin
PortForwarding 1
ControlPort 9051
SocksPort 9050
ExitRelay 0

CookieAuthFile /mnt/hdd/tor/sys/control_auth_cookie
CookieAuthentication 1
CookieAuthFileGroupReadable 1

# Hidden Service v2 for WEB ADMIN INTERFACE
HiddenServiceDir /mnt/hdd/tor/web80/
HiddenServicePort 80 127.0.0.1:80

# Hidden Service v2 for LND RPC
HiddenServiceDir /mnt/hdd/tor/lndrpc10009/
HiddenServicePort 80 127.0.0.1:10009

# Hidden Service v3 for LND incomming connections (just in case)
# https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions#Howtosetupyourownprop224service
HiddenServiceDir /mnt/hdd/tor/lnd9735
HiddenServiceVersion 3
HiddenServicePort 9735 127.0.0.1:9735

# NOTE: bitcoind get tor service automatically - see /mnt/hdd/bitcoin for onion key

[CandleHater]

We probably need to change the Tor repo to buster from stretch in line 60-61 of https://github.com/rootzoll/raspiblitz/blob/master/home.admin/config.scripts/internet.tor.sh.

First of all that and also the script doesn't check if those sources are already present in /etc/apt/sources.list, I had double entries for example. When I have time on the weekend I'll fix both and further test the Tor implementation.

[woeisme]

We probably need to change the Tor repo to buster from stretch in line 60-61 of https://github.com/rootzoll/raspiblitz/blob/master/home.admin/config.scripts/internet.tor.sh.

First of all that and also the script doesn't check if those sources are already present in /etc/apt/sources.list, I had double entries for example. When I have time on the weekend I'll fix both and further test the Tor implementation.

wouldn't it be better to use /etc/apt/sources.list.d/torproject.list so that you could merely check if the repo file exists than to write to /etc/apt/sources.list ?

I adjusted sources and run the above internet.tor.sh off after, which installed tor correctly but somehow my bitcoin.conf file was deleted / overwritten.

update
Reinstalling the sdcard and starting from scratch, this time I adjusted torproject sources on the SDcard before first boot. Everything functioned and synced up properly until enabling tor service from raspiblitz menu. After enabling install worked but machine then complained about LND being hung with repeating messages (sorry should have copied text, something along the lines of unable to connect to port).
Turned off Tor service and everything seems to have gone back to normal.

[openoms]

Relaying a suggestion from the Telegram group regarding taht we should suggest to regenarate the lnd wallet after switching to Tor.

Re Nyx:

running without sudo results to an auth failure:

$ nyx
We were unable to read tor's authentication cookie...

  Path: /mnt/hdd/tor/sys/control_auth_cookie
  Issue: Authentication failed: '/mnt/hdd/tor/sys/control_auth_cookie' doesn't exist

Does anyone have concerns with running nyx as root?

This warning is a coming up repeatedly, maybe connected to the issues with Tor?

│ 15:30:04 [WARN] /run/tor is not owned by this user (bitcoin, 1002) but by debian-tor (111). Perhaps you are running Tor as the wrong user?...

[woeisme]

Relaying a suggestion from the Telegram group regarding taht we should suggest to regenarate the lnd wallet after switching to Tor.

Re Nyx:

running without sudo results to an auth failure:

$ nyx
We were unable to read tor's authentication cookie...

  Path: /mnt/hdd/tor/sys/control_auth_cookie
  Issue: Authentication failed: '/mnt/hdd/tor/sys/control_auth_cookie' doesn't exist

Does anyone have concerns with running nyx as root?

This warning is a coming up repeatedly, maybe connected to the issues with Tor?

│ 15:30:04 [WARN] /run/tor is not owned by this user (bitcoin, 1002) but by debian-tor (111). Perhaps you are running Tor as the wrong user?...

I'll try to look into this, I used to be very active in Tor a few years back. I believe it's probably bad to run it as root vs a tor user account with minimum viable privileges. However I'll try to link to some documentation later though.

UPDATE
NYX own documentation recommends not running as root
Why can't I see Tor's connections?
Perhaps option 3 in that list is best

Turn off DisableDebuggerAttachment by adding the following to your torrc and restarting tor...

DisableDebuggerAttachment 0

[woeisme]

Does anyone else have TOR working "out-of-the-box" on RC3 yet?
I'd prefer to use it versus opening up ports on my network but it would be nice to know where the flaw is occurring.

[fluidvoice]

@openoms

│ 15:30:04 [WARN] /run/tor is not owned by this user (bitcoin, 1002) but by debian-tor (111). Perhaps you are running Tor as the wrong user?...

The Tor install script is setting the owner of /run/tor (symlink /var/run -> /run) to bitcoin but the owner of this is getting changed to debian-tor upon reboot. That's where this warning is coming from.
https://github.com/rootzoll/raspiblitz/blob/0ee013650d9ea94733908606620cb7dddfcf88a3/home.admin/config.scripts/internet.tor.sh#L187

Edit: sorry I just saw you hit this problem 12 days ago on Odroid. No progress?
This is happening on Pi's also. See this guy's syslog in this termbin link from this issue: https://github.com/rootzoll/raspiblitz/issues/704#issue-476534859

[openoms]

Rewrote my SD on a previously working RaspiBlitz 1.3 RC1.
With the new install I get Tor errors too:

our install method clearly does not work any more:
```* Install Tor *
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
tor : Depends: libevent-2.0-5 (>= 2.0.10-stable) but it is not installable
Recommends: tor-geoipdb but it is not going to be installed
Recommends: torsocks but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

* Tor Config *
chown: cannot access '/var/run/tor/': No such file or directory```

Tor install script output on a reinstall attempt:
https://pastebin.com/raw/czbMW9TW

[fluidvoice]

15:30:04 [WARN] /run/tor is not owned by this user (bitcoin, 1002) but by debian-tor (111). Perhaps you are running Tor as the wrong user?...

(in my 1.3 VM) after running:
sudo usermod -a -G debian-tor bitcoin
the above Tor error is no longer in /var/log/syslog

though Tor still does not run. My syslog shows a Tor error "permission denied" error for the /mnt/hdd/tor/web80 dir.

This dir is owned by "bitcoin" so my guess is it's being accessed by user "debian-tor" and getting denied.

[openoms]

Same RPi4 node. Building the SDcard manually with wget https://raw.githubusercontent.com/rootzoll/raspiblitz/v1.3/build_sdcard.sh && sudo bash build_sdcard.sh v1.3 rootzoll worked. Tor installed successfully at first boot.
Based on Raspbian Buster with Desktop.
RTL still not working, the issue is open with the team: https://github.com/ShahanaFarooqui/RTL/issues/173
Will make an 1.3 RC2 for testing. Couple of people struggling to start their the RPi4-s currently.

[rootzoll]

Choosing TOR will be a two step if needed: During Setup user has to choose between PublicIP and TOR in general. And if user chooses to self-validate/sync with the Blitz it will ask again if the IBD (just for Bitcoind) can be PublicP or should also be behind TOR. Here is the info text on that second choice the Blitz will show:

Sync Blockchain from behind TOR? 
You decided to run your node behind TOR and validate the blockchain with your RaspiBlitz - thats good. But downloading the complete blockchain thru TOR can add some extra time (maybe a day) to the process and adds a heavy load on the TOR network.
Your RaspiBlitz can just run the initial blockchain download with your public IP (Public-Sync) but keep your Lighting node safe behind TOR. It would speed up the self-validation while not revealing your Lightning node identity. But for most privacy choose (TOR-Sync).

[fluidvoice]

@openoms I've played around with various settings and I think it's quite possible the problem, which appears to be rights related is due to "Apparmor" and this I think was installed by default with Debian 10 by defailt. It's also running in Raspbian, right?

[rootzoll]

Testing with TOR looks good so far on my Raspberries with Debian Buster.

[fluidvoice]

Testing with TOR looks good so far on my Raspberries with Debian Buster.

What configuration and kind of test(s) was performed so far and observed working?

[openoms]

Choosing TOR will be a two step if needed: During Setup user has to choose between PublicIP and TOR in general. And if user chooses to self-validate/sync with the Blitz it will ask again if the IBD (just for Bitcoind) can be PublicP or should also be behind TOR. Here is the info text on that second choice the Blitz will show:

Sync Blockchain from behind TOR? 
You decided to run your node behind TOR and validate the blockchain with your RaspiBlitz - thats good. But downloading the complete blockchain thru TOR can add some extra time (maybe a day) to the process and adds a heavy load on the TOR network.
Your RaspiBlitz can just run the initial blockchain download with your public IP (Public-Sync) but keep your Lighting node safe behind TOR. It would speed up the self-validation while not revealing your Lightning node identity. But for most privacy choose (TOR-Sync).

This is awesome! Agree that most users will only want to obscure their IP in relation to their LND node. Running the IBD behind Tor in every occasion would put an unnecessarily heavy load on the network. Now everyone has the choice to do as they like.

[rootzoll]

@fluidvoice with RC5 (release today). I did both options like you can see from the dialog above and they run without problem so far. Maybe give the RC5 a try as soon as its out.

[fluidvoice]

@fluidvoice with RC5 (release today). I did both options like you can see from the dialog above and they run without problem so far. Maybe give the RC5 a try as soon as its out.

yes, will try latest now. Btw really looks like in non-Raspbian OS it's related to the apparmor profile configuration. See issue tracking here. Looks like the problem for VM's is the apparmor service is installed and running by default in Ubuntu and Debian Buster but not in Raspbian. I will try to disable it and test.

[fluidvoice]

Looks like Tor works in my Debian Buster x86 VM now.
Just needed to do sudo systemctl disable apparmor.
Also, opened a research issue to track potential future inclusion of the apparmor service in Raspbian/Armbian.

[openoms]

IBD on Clearnet with Tor activated for Lightning went well, in 2days 2 hours on my RPi4 4gb + SSD: https://twitter.com/openoms/status/1162118831965446145.

Only concern was that, when the IBD finished the LND was restarted and waited to finish the blockchain scan until unlocked again. This added hours to have LND ready because it needed to scan the last ~5 percent of the blockchain. Ideally both bitcoin and LND sync should finish before restarting the services to put bitcoin behind Tor too or maybe wait for a manual trigger and keep in sync until looked at?

[fluidvoice]

edit: moved to revisiting fast-sync subject

[woeisme]

@fluidvoice with RC5 (release today). I did both options like you can see from the dialog above and they run without problem so far. Maybe give the RC5 a try as soon as its out.

@rootzoll what's the best way to backup an existing installation to try out RC5 ?
Is there any method for cutting down on startup time?

[fluidvoice]

@fluidvoice with RC5 (release today). I did both options like you can see from the dialog above and they run without problem so far. Maybe give the RC5 a try as soon as its out.

@rootzoll what's the best way to backup an existing installation to try out RC5 ?
Is there any method for cutting down on startup time?

https://github.com/rootzoll/raspiblitz#backup-for-on-chain---channel-funds

[rootzoll]

Only concern was that, when the IBD finished the LND was restarted and waited to finish the blockchain scan until unlocked again. This added hours to have LND ready because it needed to scan the last ~5 percent of the blockchain. Ideally both bitcoin and LND sync should finish before restarting the services to put bitcoin behind Tor too or maybe wait for a manual trigger and keep in sync until looked at?

I will check on this before final release - but maybe such optimization will get pushed to next released to not further delay the v1.3 release.

[woeisme]

@fluidvoice with RC5 (release today). I did both options like you can see from the dialog above and they run without problem so far. Maybe give the RC5 a try as soon as its out.

@rootzoll what's the best way to backup an existing installation to try out RC5 ?
Is there any method for cutting down on startup time?

https://github.com/rootzoll/raspiblitz#backup-for-on-chain---channel-funds

Is this the preferred method for switching between 1.3rc3 -> 1.3rc5 without losing funds?

[rootzoll]

@woeisme on v1.3rc3 you can use the "UPDATE" option in the SSH main menu and just use "continue anyway" if reported that no new version is available.

[rootzoll]

@openoms pushed optimization to future release: see here #750 so that I can release v1.3 this week and dont need re-testing a 2 day long process. It should work good enough for now.

[codeoholic]

Hey @rootzoll @openoms post v1.5.1 update. I am seeing this in TOR logs.

/run/tor is not owned by this user (bitcoin, 1002) but by debian-tor (111).
Before Tor can create a control socket in "/run/tor/control", the directory "/run/tor" needs to exist, and to be accessible only by the user.

Can you help me understand what exactly is going here and a possible solution.

[rootzoll]

@codeoholic those warnings are not critical - see issue: https://github.com/rootzoll/raspiblitz/issues/402

The idea is to clean this up, when we make TOR by default in an upcoming version.

[codeoholic]

Okay. I was thinking this could be the reason for the LND REST service being unreachable via TOR. If this is normal, could you point me how to debug it?

[rootzoll]

To monitor TOR connections check the MAINMENU > TOR ... thats the nyx TOR Monitor:
https://nyx.torproject.org