Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TOR why non-persistent server? #2476

Closed
NicolasDorier opened this issue Mar 15, 2019 · 8 comments
Closed

TOR why non-persistent server? #2476

NicolasDorier opened this issue Mar 15, 2019 · 8 comments

Comments

@NicolasDorier
Copy link
Collaborator

To my surprise, autotor create a new onion address at every starts.

Why has it been done that way? Basically all my channels will happily break every times I restart c-lightning.

@kristapsk
Copy link
Contributor

Open channels does not break when your node's address change.

@NicolasDorier
Copy link
Collaborator Author

NicolasDorier commented Mar 16, 2019

@kristapsk well other nodes which have a channel with me are expecting to connect to my node through a certain address.

Moreover there is no reason to change address at each reboot as your identity is your node pubkey, which is fixed.

@Saibato
Copy link
Contributor

Saibato commented Mar 16, 2019

@NicolasDorier as long as you only restart lightning but not the tor service all created autoservice v2 onion are persistent as long as the tor demon run's and are useable in parallel.
Please note me, if this is not true on your nodes, as I don't test on alpine.

For real static v2/v3 onion's, edit the torrc file and make a --bind-addr and/or --announce-addr, I think is the preferred way.

sure with HSFETCH we could check if some service is still active and reuse it, but the idea was to have onion's that can change and are somewhat hidden. so that some or all channels are only useable if you know the peers onion name and do a reconnect on the peerid with the changed onion address.
If you know it, it's like kind of access token, some nodes might prefer to be hidden when the power fails and not to restart with the same config.

@rustyrussell
Copy link
Contributor

Yes, we use temporary addresses with autotor. For persistent addresses, I expected people to configure Tor statically.

We could add a persistent option, but not sure how we'd make sure we got the same one (haven't investigated).

@NicolasDorier
Copy link
Collaborator Author

I ended up to configure Tor statically, which is not that bad.

I just don't understand the rational of having non-permanent address.

so that some or all channels are only useable if you know the peers onion name and do a reconnect on the peerid with the changed onion address.

This seems impactical to me, so this mean that everytimes my service reboot (tor & clightning), I would need to manually tell my peers about the new onion address?

Because if it is not done manually, and you advertize it, then your pubkey is already your ID.

@Saibato
Copy link
Contributor

Saibato commented Mar 19, 2019

Because if it is not done manually, and you advertize it, then your pubkey is already your ID.

yup, sometimes I think tor's only use is to enable services behind a NAT. That's why I don't really care about v3, as I don't want to leave the impression that one is more hidden than the other

every metric tent's over time to be exploited, so I am a fan of human interaction and consensus
ethics is about what we program and what not

@NicolasDorier
Copy link
Collaborator Author

NicolasDorier commented Mar 19, 2019

@rustyrussell this is quite easy to get same one actually.

When you call ADD_ONION NEW RSA1024, TOR generate a private key for you that you can save in the data folder.

When you restart, if you find this private key in the folder, just use ADD_ONION RSA1024 <privateKeyBlob> (without NEW) and you will be assigned the same address. (The private key is actually what define your address)

@ZmnSCPxj
Copy link
Contributor

Already fixed in #3155 I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants