ff/ an example how to use this parameter

diff --git a/src/torcontrol.cpp b/src/torcontrol.cpp
index 84118b36e..3131e6793 100644
--- a/src/torcontrol.cpp
+++ b/src/torcontrol.cpp
@@ -532,7 +532,7 @@ void TorController::auth_cb(TorControlConnection& _conn, const TorControlReply&
         }
 
         // Finally - now create the service
-        if (private_key.empty()) // No private key, generate one
+        if (private_key.empty() || gArgs.GetBoolArg("-ephemeraltoronion", DEFAULT_EPHEMERAL_TOR_ONION)) // No private key, generate one
             private_key = "NEW:RSA1024"; // Explicitly request RSA1024 - see issue #9214
         // Request hidden service, redirect port.
         // Note that the 'virtual' port is always the default port to avoid decloaking nodes using other ports.

This has been proposed before, but I still don't think this is particularly useful:

• You can already achieve this by deleting the private key file (~/.bitcoin/onion_private_key) before launch.
• It takes quite a while to gossip a generated onion address over the network, the average run time of bitcoind is likely not long enough to get any incoming connections. So then, why create an onion service at all?

This has been proposed before, but I still don't think this is particularly useful:

@laanwj .... not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

the` average run time of bitcoind is likely not long enough to get any incoming connections

tyi, I had often probing inbound connections even after one restart when testing transition to v3.

@laanwj .... not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

I have no idea what you're trying to say here, or why the situation would be any different for v2 vs v3.

@sipa

I have no idea what you're trying to say here, or why the situation would be any different for v2 vs v3.

I want not go further since i did not file a tor trac all those years and also doubt tor will ever change v3 directory and relay logic for an ip dox prone app as is.

tyi; while i dev'ed the base layer in tor support for c-ln some years ago, i stumbled upon an v3 tor edge case and when testing core and dev'ed my private v3 in old v2 ADDR ipv6 tunnel message non BIP tunnel patch, i saw it again against the ADDRv2 test nodes,

But aside all of this, genuine temporary V3 addr might be useful to have for one shot side synced pruned top version nodes that just want stealth tx or for those that are always behind a NAT but also want not there ip or region known but enable short time inbound they advertise by other means, ie, over c-ln invoices or DLC's

btw, since AFAICS u came up with the wrapped in ipv6 v2 address PR #1174 after enable #1021 and use the OnionCat addr space , i really keen to know what was the motivation in first place to do it that way then?

while i dev'ed the base layer in tor support for c-ln some years ago, i stumbled upon an v3 tor edge case and when testing core and dev'ed my private v3 in old v2 ADDR ipv6 tunnel message non BIP tunnel patch, i saw it again against the ADDRv2 test nodes,

Ok, what is the edge case? I have a very hard time understanding you.

But aside all of this, genuine temporary V3 addr might be useful to have for one shot side synced pruned top version nodes that just want stealth tx

For broadcasting over Tor you don't need a hidden service at all.

or for those that are always behind a NAT but also want not there ip or region known but enable short time inbound they advertise by other means, ie, over c-ln invoices or DLC's

Agree, in theory that seems useful and feasible. But in practice I have not seen demand for such a mode of operation. It's also independent of v2 vs v3.

btw, since AFAICS u came up with the wrapped in ipv6 v2 address PR #1174 after enable #1021 and use the OnionCat addr space , i really keen to know what was the motivation in first place to do it that way then?

It was an easy and somewhat standardized way of making the network relay onion addresses without protocol changes. Perhaps it was a mistake in retrospect, and we should have done something like BIP155 back then immediately, but that was not something I was considering.

not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

@Saibato Not sure why we will need new address on each restart for v3

Also sipa mentioned it will affect the way node works and end up not listening to anyone. We need a solution which doesn't affect the functionality and also improves the privacy. I am not sure what kind of attacks are possible if same address is used for long time. I need to experiment more, research, consult few experienced people who are involved in things related to Tor like author of this post: https://www.hackerfactor.com/blog/index.php?/archives/896-Tor-0day-Finding-IP-Addresses.html

@prayank23

it will affect the way node works and end up not listening to anyone

Its often just the seeders big address list view that u get at first start of your node and the randomness and addrman logic of outbound node selection can take a while to get you node considered for outbound, what will be your v3 service inbound
That does not mean no one gets the ADDR mesg fast or sees your v3 address a bit local in the tor dir messages , we could even change the code, to prio v3 nodes if underrepresented in the connect list.
But the main point i have here, is the problematic for outbound in general after a while of ADDR/ADDRv2 messages , if parts of the net get spoofed and MITM
and see not the real chain.

need new address on each restart for v3

not need, more new v3 on restart should be the default, for privacy

author of this post: https://www.hackerfactor.com/blog/index.php?/archives/896-Tor-0day-Finding-IP-Addresses.html

My definition of 0-Day is a bit different and all what was mentioned in the link and by the author of it, is to my knowledge not news or surprising to tor devs. Tor bug trac is an ugly process and it can happen they don't even mention u if u just hint.
But hey if they care about fame when dev for Tor, Tor is probably the wrong place for that, i can not complain that they did not do there best to address bugs or patches I posted. imho.

BTW: A real 0-Day comes out of the blue, hits hard and drops your jaws

@sipa .

Ok, what is the edge case? I have a very hard time understanding you.

An edge case is, when something happens only if special sequences of crafted or random probability events predate that event, if not the software works as intended.

For broadcasting over Tor you don't need a hidden service at all.

Correct but that i don't call sooooo stealth,,,
My point is that i like to use temp on the fly tor nodes remote inbound that create there address like c-ln from a blob or trusted hash sequence or address key byes ( prove of key ) , from a hidden poller that forwards, further.

but that was not something I was considering.

yup shit happens, that;s why i say never rush and for myself i like harsh reviews and no bonus for commit counts, that's why i often change my names and avatars, so never hesitated to call me out if i am wrong, 🥳

We have still some time until v2 fades out and that should be used to the limit, for review and testing.
And if seeders would add there v3 addr now in chainparams.cpp and disable doxing ipv4 seeding if -onlynet=onion we would have even now out/inbound v3's and could easy bootstrap full in Tor also with v3, that i would like and that would btw be a good testbed for the advertised seeders v3 nodes,

i.e.

diff --git a/src/chainparams.cpp b/src/chainparams.cpp
index ffd2076c9..4903e3bda 100644
--- a/src/chainparams.cpp
+++ b/src/chainparams.cpp
@@ -10,6 +10,7 @@
 #include <tinyformat.h>
 #include <util/system.h>
 #include <util/strencodings.h>
+#include <util/system.h>
 #include <versionbitsinfo.h>
 
 #include <assert.h>
@@ -113,6 +114,7 @@ public:
         // This is fine at runtime as we'll fall back to using them as an addrfetch if they don't support the
         // service bits we want, but we should get them updated to support all service bits wanted by any
         // release ASAP to avoid it where possible.
+        if (gArgs.GetArg("-onlynet", "") != "onion") {
         vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
         vSeeds.emplace_back("dnsseed.bluematt.me"); // Matt Corallo, only supports x9
         vSeeds.emplace_back("dnsseed.bitcoin.dashjr.org"); // Luke Dashjr
@@ -122,6 +124,11 @@ public:
         vSeeds.emplace_back("seed.bitcoin.sprovoost.nl"); // Sjors Provoost
         vSeeds.emplace_back("dnsseed.emzy.de"); // Stephan Oeste
         vSeeds.emplace_back("seed.bitcoin.wiz.biz"); // Jason Maurice
+        };
+
+        if (gArgs.GetArg("-onlynet", "") == "onion") {
+        vSeeds.emplace_back("sipasv3onionaddressasdasdasdasdad.onion:8333"); // Pieter Wuilles onion v3 address
+        }
 
         base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,0);
         base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,5);
u

@Saibato You never answered this:

@laanwj .... not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

All I can see is you arguing that ephemeral onion addresses are useful, but nothing specific about v3. If there are specific arguments in favor of that, or "edge cases", I'd like to see them spelled out concretely. Please don't tell people to "be assured" without backing up your point.

Correct but that i don't call sooooo stealth,,,

It's the most private approach there is... you don't have any identifier at all, not even an ephemeral one. I really don't know what you're trying to say. Please be specific.

not need, more new v3 on restart should be the default, for privacy

I think this is a bad idea. If you're that concerned about privacy you should just disable listening entirely, and not create hidden services - not even ephemeral ones.

Creating new ones on restart makes the privacy/usefulness tradeoff dependent on how frequently your node restarts. If you restart all the time, it's equivalent to not having a hidden service at all. If you never restart, it's equivalent to having a persistent onion address. If this is an interesting tradeoff at all, it should be an option to configure how frequently to create a new one - but I don't think that anything less than days or weeks even is useful.

@sipa

It's the most private approach there is...

Hmm, never trust the NSA footprints in Tor and Bitcoin?, I like chained inbound services created like in c-ln that can use the non clamped full edwards key space,

The standard keygen call we use now, id liked anyway replaced (PRNG and clamping) , to have full keys.
But that would make bitcoin almost a privacy coin and then Wall Street and HRT might get mad at us?

@Saibato You never answered this:
not for v2 that was dismissed and like you said could be easy mitigated, but be assured you will want that in some form for v3, just a hint

Sorry but i cant ...

I like chained inbound services created like in c-ln that can use the non clamped full edwards key space,

I see no reason to deviate from standard cryptographic constructions for this.

If you want to have a reachable onion service but not have it result in an identity, just don't advertize it.

My question above was why you were stating that not creating a hidden service at all is less private than an ephemeral one, but perhaps I misunderstood you.

If this is an interesting tradeoff at all, it should be an option to configure how frequently to create a new one - but I don't think that anything less than days or weeks even is useful.

@sipa even I was thinking about having such option. Maybe if enabled it should either ask the user to save the time interval or randomly delete the file once in every few days. Random because it will avoid any pattern that someone may observe.

There seems to be agreement that there doesn't need to be specific functionality for "ephermal onions". If you do not want your node to be reachable on an onion address it's best to disable -listenonion. There's no point in having time-limited onion addresses in bitcoin, the time it takes to gossip an address and for other peers to really connect is long enough that it's undesirable to repeat that process every time. So better to just disable it than bother with extra complexity to say, rotate private service keys.

And if you really, really want this functionality it can already be achieved from outside by say, a crontab, deleting the onion private key periodically and restarting bitcoind. Or even by managing Tor's configuration yourself.

In any case I'm repeating myself here, closing this PR.