search

zcash / zcash

Zcash - Internet Money
https://z.cash/
Other
4.93k stars 2.03k forks source link

Rebooting overlay support: Merge v3 onions (critical), I2P SAM, and CJDNS from upstream Bitcoin. #6075

Open nullianity opened 2 years ago

nullianity commented 2 years ago

Today, on the first anniversary of the 15 July 2021 official end of life for onion v2, I respectfully request that Zcash change some development decisions to prioritize v3 onions—and other overlay networks.

The deadline for fully fielded v3 onion support passed one year ago. Tor nuked onion v2 from orbit almost nine months ago. v2 onion is insecure, EOLed, unsupported—and now, as of a few weeks ago, totally nonfunctional on the Tor network. Accordingly, it is fair to say that Zcash does not support onions.

Upstream Bitcoin Core has first-class support out of the box for the following privacy and/or censorship-resistance networks—all of which could be borrowed, without wasting Zcash dev cycles on reinventing the wheel:

(This list is copied from my forum post of almost two weeks ago. If I can spare the time and effort to work out a Github task list of commits, alone or working with others here, I will edit this issue.)

Please reboot the approach here:

I am aware that the Zcash developers have some nitpicks over how Bitcoin did this. Although my concerns are different, I myself think that it was slightly suboptimal. I wish that I had bikeshedded spoken up during the BIP 155 standardization process. Well, it is what it is—and it works! The code is written, tested, fielded. It has been used in mission-critical settings every day for the past year and a half. Please don’t let the perfect be the enemy of the good.

Here, and generally, I urge trying to keep a closer alignment with upstream.

Zcash has a small dev team at a single company, with spectacular world-class expertise in a narrow specialty: Zero-knowledge proof privacy. Bitcoin Core is a massive effort with a large number of highly competent contributors, funded generously by decentralized, voluntary private grants from numerous parties around the world. The fruits of all that funding and labour are all MIT-licensed, freely available for Zcash to enjoy in the open-source spirit of give-and-take.

Zcash has already richly benefitted from this: If Zcash had tried to write its own node from scratch, I estimate that in the best case, Zcash would have shipped its first mainnet at least two years later than it did—at a cost of many millions of dollars in additional development effort, never mind opportunity costs. (Best case. Many such projects stall out and fail as vapourware.) Since then, Zcash has obtained many of its best non-blockchain-privacy improvements from upstream. Bitcoin Core has a huge codebase under continual improvement, just waiting to be copied. Please, take advantage.

Staying fully aligned with BIP 155 and Bitcoin Core’s implementations of support for Tor onion v3, IP2 SAM, and CJDNS gives Zcash what it needs now yesterday a year ago, and it lets Zcash continue to borrow from Bitcoin for the future maintenance burden. Doing things differently would saddle Zcash with technical debt of the worst kind: The kind that Zcash developers need to maintain in perpetuity, all by themselves.

Staying closely aligned with upstream means that future features and improvements can be cherry-picked with minimal effort. As a developer interested in writing third-party code that interacts with both Bitcoin and Zcash (including on the P2P network level for added network-layer privacy), I note that a close alignment on BIP standards facilitates ecosystem growth—mainly to Zcash’s benefit. To Bitcoin, the market-dominant ecosystem with vast network effects, the ecosystem benefit here is negligible.

Speaking as a Zcasher since Sprout and a long-term ZEC holder, I think that the foregoing is more important to Zcash than any theoretical inelegance in BIP 155.

Speaking as a Tor user who ran zcashd with onlynet=onion for over five years, I identify this as a major pain point for Tor users.

Speaking as a Bitcoiner-Zcasher, I am frustrated by how many excellent bitcoind features are missing from zcashd. This will be only the first of my efforts to point out the most important, real-world practical features where Zcash needs to catch up by copying more of Bitcoin’s reviewed, tested, freely available MIT-licensed code.

nullianity commented 2 years ago

Cross-reference for anyone following this issue: @str4d is working on Tor onion v3 at https://github.com/zcash/zcash/pull/5366#issuecomment-1186937917, et seq.

metalworker2 commented 1 year ago

As the Tor project website says, v2 addresses were fully deprecated in October 2021:

In July 2021, 0.4.6 Tor will no longer support v2 and support will be removed from the code base.

In October 2021, we will release new Tor client stable versions for all supported series that will disable v2.

Source: https://support.torproject.org/onionservices/v2-deprecation/

As of today, Tor v3 addresses are still not supported in zcashd. This means Zcash devs are almost one year late on their promise made in the Zcash documentation where it says:

Note that zcashd does not yet support Onion v3 addresses, but will do so before v2 addresses are removed from Tor.

Source: https://zcash.readthedocs.io/en/latest/rtd_pages/tor.html#expose-your-zcashd-via-a-tor-hidden-service-optional

As a (former?) zcashd hidden service operator who also strongly prefers to only connect to other hidden service nodes, I have been unable to use Zcash for nearly a year.

Being that this is a privacy-focused project, I urge Zcash devs to use the Dev Fund that Zcash consensus provides to support the privacy of users via Tor v3 support or provide another, "officially supported", even higher-quality option for anonymizing the network layer without trusted third parties ASAP, very high priority.