Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-10 📝 Original message: There isn’t a lot to do ...
đź“… Original date posted:2021-06-10
đź“ť Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
đź“ť Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev