Cherry-picking Tor onion v3 and other overlay networks from Bitcoin

nullius · July 15, 2022, 11:46pm

Update: Today is the first anniversary of the 15 July 2021 official deadline for deprecation of v2 onions. Earlier today, I raised a Github issue with the same request.

github.com/zcash/zcash

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

opened 08:04AM - 15 Jul 22 UTC

nullianity

use case

Today, on the first anniversary of [the **15 July 2021** official end of life fo…r onion v2](https://blog.torproject.org/v2-deprecation-timeline/), 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.](https://gitlab.torproject.org/tpo/core/tor/-/issues/40476) 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: * **Tor onion v3:** Issue bitcoin/bitcoin#18884, main PR bitcoin/bitcoin#19954, merged 2020-09-14, released in Bitcoin Core v0.21.0 on 2021-01-14. Other PRs relate to v3 onion support; the whole Bitcoin infrastructure was upgraded to onion v3 well in advance of the Tor Project’s 2021-07-15 deprecation deadline for v2 onions. As @daira noted (https://github.com/zcash/zcash/issues/5277#issuecomment-903833687), Bitcoin totally removed its v2 onion support shortly after that deadline had passed. * **I2P SAM:** bitcoin/bitcoin#20685, merged 2021-03-02, released in Bitcoin Core v22.0 on 2021-09-13. * **CJDNS:** bitcoin/bitcoin#23077, merged 2021-11-08, released in Bitcoin Core v23.0 on 2022-04-25. (This list is copied from [my forum post of almost two weeks ago](https://forum.zcashcommunity.com/t/cherry-picking-tor-onion-v3-and-other-overlay-networks-from-bitcoin/42421). 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](https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki) 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.

I also opened zcash/zcash#6076 to request merging to Zcash a Bitcoin Core RPC that some privacy wallets use with Tor, to facilitate unlinked sending of transactions. Please see below for a brief description of the optimal use case.

I am disturbed by an unavoidable question: How many people in this community use Tor on a regular basis? The Zcash Foundation’s website, zfnd.org, blocks Tor and continues to block it five days after I reported the issue. (I understand that it takes reasonable time to dump a bad provider, and switch to Tor-friendly hosting; but it has been five days, with no resolution in sight.) Discord is unaccountably popular, despite its infamous hostility to Tor users. And… Zcash totally lacks support for onions. As I have remarked elsewhere, v2-only support is like “supporting” the old v0/v1 “Hidden Services”: It is means no support for onions.

Does anyone around here actually use Tor—I mean use it for ordinarily daily activities, not merely tried it sometime? @nickm_tor? Tor is well-supported in Bitcoinland, because so many Bitcoiners actually use it every day. Satoshi himself was a Tor user!

As a longtime privacy activist, I seek positive changes here. I intend to advocate here for Zcash, Tor, PGP, and general privacy best-practices.

On `getnodeaddresses` (zcash/zcash#6076)

In brief, the optimal use case for #6076: Use the getnodeaddresses RPC to obtain from the node a list of known peer addresses. Open a P2P connection to a random peer (preferably, but not necessarily an onion peer). Send one transaction. Close the connection.

If used properly with Tor’s circuit isolation features, this remediates one of Zcash’s biggest privacy problems: Linkability of txids by spy nodes, using well-known means to ascertain with more or less high probability which node originated a transaction.

See the ticket for links to Bitcoin privacy projects which have been doing exactly that for years.