There isn’t a lot to do at the spec level to deprecate them - nodes should start ignoring the addresses bug nodes always need to know the length/parse v2 Onion addresses forever as well as store and forward them. We could amend the spec to say that nodes shouldn’t produce them but it won’t change the receive/process end much.
> On Jun 1, 2021, at 18:19, darosior via Lightning-dev > <lightning-dev@lists.linuxfoundation.org> wrote: > > Hi all, > > It's been almost 9 months since Tor v2 hidden services have been deprecated. > The Tor project will drop v2 support in about a month in the latest release. > It will then be entirely be dropped from all supported releases by October. > More at https://blog.torproject.org/v2-deprecation-timeline . > > Bitcoin Core defaults to v3 since 0.21.0 > (https://bitcoincore.org/en/releases/0.21.0/) and is planning to drop the v2 > support for 0.22 (https://github.com/bitcoin/bitcoin/pull/22050), which means > that v2 onions will gradually stop being gossiped on the Bitcoin network. > > I think we should do the same for the Lightning network, and the timeline is > rather tight. Also, the configuration is user-facing (as opposed to Bitcoin > Core, which generates ephemeral services) which i expect to make the > transition trickier. > C-lightning is deprecating the configuration of Tor v2 services starting next > release, according to our deprecation policy we should be able to entirely > drop its support 3 releases after this one, which should be not so far from > the October deadline. > > Opinions? What is the state of other implementations with regard to Tor v2 > support? > > Antoine > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
