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

I respectfully request that v3 onions be prioritized. I know that the Zcash dev team dislikes Bitcoin’s approach to this. Please don’t let the perfect be the enemy of the good. My perspective: I have been using zcashd with onlynet=onion since Sprout. It was beyond painful long ago, and it is probably far past the point of a false sense of privacy and security.

The v2 deprecation deadline passed almost a year ago; and Tor nuked onion v2 from orbit almost nine months ago. Thus, it is fair to say that Zcash does not support onions. It is a strange state of affairs, when @nickm_tor has an account here, Zcash funds such projects as Arti, etc. I don’t want to be a complainer, but this is an important feature for which fully debugged, field-tested code can be cherry-picked.

Indeed, 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 copied, 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, Bitcoin 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.

Although its blockchain privacy is practically nonexistent, Bitcoin’s network-layer privacy is currently much better than Zcash’s (for this and other reasons that I will discuss on a relevant thread). Moreover, support for overlay networks gives robust censorship-resistance. It even helps security, insofar a node with peer connections on multiple overlay networks should be more difficult to eclipse, even for a powerful AS-level adversary. (Core also has some more or less recent connection manager changes to resist eclipse attacks, which could be cherry-picked; but that is a separate issue, probably one that I should raise on Github if I wish to request it.)

Thanks in advance for perhaps reconsidering the approach to this—and thanks for making Zcash!

4 Likes

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.

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.

1 Like

I have met multiple Zcashers that do. I personally use Tor for outgoing connections to (regular) nodes, and also run a zcashd instance that is accessible over a v3 onion (via AutomapHostsOnResolve). My node averages over 100 incoming connections and used to also have a v2 onion.

The getnodeaddresses idea for transaction broadcast with circuit isolation is excellent! I hope Zcash adopts it. But even before that, v3 onion support is really overdue.

To keep track of Tor-related things in the Zcash ecosystem – last time I tried, ZecWallet Lite did not work in Tails (due to both a long-standing bug in Electron and gRPC issues).

2 Likes

A great thing about Zcash: I am admittedly somewhat distraught by some of what I’m finding, and I ask who around here even uses Tor—and up pops this reply:

Please don’t tell me that they’re all students on East Campus. We also need some Westies to make for a proper “anonymity set”. :joy_cat:

Interesting. How is it discoverable, since it can’t be gossipped? (Asking for a friend.)


Thanks for your comments. Zcashland at its finest—and a fine endorsement of Tor, I may add. Please be forewarned that after I finish catching up on things to be worried about, I may try to hit you and the other Zcash forum cryptographers up with positive ideas for awesome things that Zcash could make happen. I’d be thrilled to discuss creative brainstorms for how by the magic of cryptography, the coin with hands-down absolutely the best blockchain privacy could better leverage its ecological niche, reach new markets, and influence changes on the wider ecosystem. —Right after I wonder aloud if anyone around here knows anyone from DCI who could ask Wladimir for advice on how to catch up to feature parity with Bitcoin Core 23.0… Maybe Zcash should spend development money on that, instead of on memes and videos.

1 Like

There are two primary reasons this didn’t happen last year before the October deadline for v2 removal:

  • The ECC core team was busy with NU5; we’ve been working on it solidly for over a year and a half at this point and are still not finished (there is a bunch of mobile wallet work left to do).
  • The backport is not as simple as cherry-picking the ADDRv2 and Tor v3 support. All of the upstream changes assume the existence of a bunch of other upstream PRs that we don’t have (and that I’ve been slowly trying to get backported over the years, but we’re a small team with a responsibility to safely backport changes in a way that does not break Zcash, and Bitcoin Core was not designed to be modular in a way that makes backports easy and safe).

I’m very grateful to ZingoLabs, which put in a bunch of work last year to figure out (most of) the required upstream commits that need to be landed in order to unblock ADDRv2 support. Their current draft PR ostensibly does have Tor v3 support (I believe it was working inasmuch as they had Tor communication functioning in a private testnet). However, it is not at all feasible to just merge the PR as-is: there are far too many changes to review at once, a bunch of tests are currently commented out, and the interactions of the PRs that the changes are sourced from (both with each other and the rest of the codebase) need to be carefully checked (as we have found upstream changes before during review that were innocuous upstream but would have been a subtle consensus-breaking change had we applied them to Zcash).

I’ve just spent several hours mapping the commits back to their corresponding upstream PRs, de-duplicating and sorting them to optimise for path-of-least-conflicts[1]. Currently there are 54 upstream PRs that need backporting, and that is an underestimation as it doesn’t account for the various partial backport commits that ZingoLabs included without upstream attribution (because the corresponding upstream PRs couldn’t be applied due to even more inter-PR dependencies that need to be discovered).

The next steps here are:

  • Someone (read: me) has to go through the list of PRs and turn them into a dependency graph, to figure out which PRs absolutely need to be backported before which others, and which can be worked on in parallel.
  • Then we start from the front of the graph, and try backporting the PRs in small relevant groups.
    • Every time we run into a conflict, we need to investigate it to determine if it is a meaningful conflict that introduces another backport dependency, or if it is a conflict we can work around (either because the upstream PR it conflicts with introduces a feature we definitely won’t be backporting, or we feel that the maintenance burden introduced by the conflict is small enough that we can deal with it later).
    • For every backported PR, we also need to scour the affected files upstream to find subsequent PRs that touch the same code, and determine whether we need to backport those as part of the same PR group (because it is quite common for a feature to be merged upstream and then subsequent bugfix PRs to be merged, and it would be irresponsible of us to just merge the PR dependencies of Tor v3 without conducting this kind of review).
  • Hopefully the backports proceed smoothly and only touch code that requires only one or two reviewers.
    • For anything that affects consensus code, we require for safety 3 reviews with at least 2 from ECC. This usually means 4 ECC core team engineers need to be involved in a single PR. We have 6 ECC core team engineers, so you can see how easily this step can be a bottleneck.
    • Given that this feature involves a lot of networking code, we will likely need the ZF engineers to be in the loop for some of the backports as well, given that any network-related PR we backport that has an associated BIP needs “P2P consensus” (in that zcashd and zebrad need to agree on what the P2P protocol versions mean).
  • Keep doing this until we reach the end of the graph (namely, the Tor v3 PR is backported and merged).

Hopefully this gives a bit of insight into why this has been slow. Do not mistake that for a lack of desire to support Tor v3, or I2P (I’m an ex-I2P developer, and I2P Integration · Issue #1111 · zcash/zcash · GitHub has been open since 2016). It’s just a lot, and there’s been a lot going on these past few years (both within Zcash, and in the wider world) that consumes energy and resources.

[1] and then another hour writing this message

11 Likes

It was gossiped as a v2 onion but for a v3 one you could have noticed a distinctive reverse DNS name, went to its website and found the v3 onion dankdoggo6aq2amfesdg6vin742ciiuapaoow2z3wnxzctjuazjjb5qd.onion :slight_smile:

2 Likes

Thank you for the very thorough and informative write-up! I had not realized that v3 Onion networking changes went that deep and it really made me appreciate how much work goes into backporting bitcoind improvements.

2 Likes

Thank you, @str4d. I don’t want to distract you from this very important work—I’ve just been absorbed in looking at it, and maybe preparing to throw a party here! I will properly restrain my GH comments to things appropriate to GH, if needed, while discussing here something that needs attention from the community. (Will follow up with a longer post here.)


Woof. I noticed dankdoggo6ap7njt.onion years ago. The cute name gave me a smile, but I never thought to search for information about it. :dog:


Subject of a longer post soon. For historical reference, you may also want to examine the task list at zcash/zcash#2074. (For historical reference: Some of the incomplete items were obsoleted by later Bitcoin improvements that str4d merged, e.g., anything about OpenSSL.) That was an attempt to reach feature parity with Bitcoin Core v0.12—after the recent renumbering, consider it Bitcoin Core v12. Bitcoin Core is currently shipping at v23, working on the next one.

2 Likes

I regret that looking back, my first reply to Madars may have unintentionally come off as a bit snippish towards Zcash developers. My concern is about the state of Zcash development. Besides the urgent issue of onion support, one of my longtime major pain points is that Zcash is far behind Bitcoin Core in every way except for blockchain privacy. It is even behind in network-layer privacy.

I suffered with that in silence, because I saw Zcash altogether as a small, scrappy upstart with minuscule resources compared to Bitcoin Core’s large, decentralized development effort. I thought I should be grateful that a tiny team with limited funding was achieving one highly difficult, extremely important task to change the world. Their work on blockchain privacy has been superb!

I am not saying that to sugar-coat criticism. I have a hard personality, and a reputation for never sugar-coating anything. I have been clinging to my precious ZECs, for exactly one reason: The Zcash people (inside and outside ECC) created, implemented, deployed, and refined the first and, thus far, only fully-fielded mainnet on-chain privacy technology that I deem adequate. Their key developers are specialized in that, and I want for them to stay focused on it. So, ok, I guess they can’t afford to hire enough node developers to keep the node up to date.

Then, shortly before my last posts on this thread, I perchance happened across this in a massive thread that I have barely even begun to skim—boldface is in the original:

That, and many similar posts, pertain to funding to make promotional videos. It was even suggested that a fixed percentage of ZEC developer-seigniorage funding should be allocated to the video-makers on an ongoing basis. As a ZEC holder, I protest that that would be outright unethical. As a ZEC holder who has previously defended the Zcash “dev tax” in other venues with my argument that “open-source developers need to be paid somehow”, it suggests to me that perhaps I have erred.

So… @ZcashGrants has so much money that people seriously argue, in substantial effect, that they need to make multimillion-dollar grants just to find a way to spend it? —While the zcashd node is light-years behind Bitcoin Core? While @str4d, a specialist in zero-knowledge proof systems, is struggling to find time for the tedious work needed to merge a few long-overdue improvements from upstream?

Something is wrong with this picture.

The outside view that the Zcash grant system is presenting to others: People are popping up asking free start-up money for unrelated businesses. In this case, a request for $47,000 for a cannabis retail shop:

Regardless of whether or not that gets funded, money is just being thrown around here:

How about using development funding money to fund development? :crying_cat_face:


A constructive solution.

Some people seem completely unaware of any real information about Bitcoin. If one learns about Bitcoin from Bitcoin-bashing Twitter altcoin memes, one may be blissfully ignorant of how far ahead Bitcoin Core is everywhere except privacy. Stunningly far ahead. Upstream is thriving—all funded by voluntary grants, as I have repeatedly noted.

Running both side-by-side tends to make one wish to copy the shielded value pool functionality from Zcash, and paste it onto Bitcoin so as to have everything good in one place. I believe that that was the original intent of Zcash’s design as a Bitcoin codefork—that, and gaining the market advantage of ecosystem compatibility (something that I urge the Zcash developers to keep!)—that, and getting much faster time-to-market, saving millions in development costs, and even making the project feasible. (Many altcoin projects that attempt rolling their own blockchains stall out as vapourware—or worse, produce a buggy, insecure mess.) Zcash has benefitted immensely from Bitcoin Core’s MIT-licensed codebase.

Now, if @ZcashGrants has so much money that it can’t figure out how to spend it (!), perhaps ECC should ask the community to hire a dedicated developer to help get zcashd up to parity with Bitcoin Core 23+, and to maintain it at parity going forward.

No, I am not suggesting myself for that job—and I have not yet asked around about this. I do think that I am competent to help review the qualifications of any candidates, and to give feedback on paid performance. It should be someone with strong qualifications on the Bitcoin side, who has a deep familiarity with the code and who follows Bitcoin development very regularly. Maybe even see if any well-established Bitcoin Core contributors would be interested in a paid position working full-time to get the Zcash node fully up to date, and thereafter part-time on an ongoing basis to keep it up to date.

I am aware of The Mythical Man-Month. But the task here is well-defined: Do for years worth of missing features and fixes the intellectually demanding, but tedious and time-consuming work that @str4d is now doing for Tor v3 onions, and has done before for other fixes and features. Then, submit it for review. I applaud this and other review criteria:

That way, ECC team members only need to perform reviews—instead of doing the preparatory work, and then also performing a sufficient peer review process.

The benefits are many.

In addition to the extensive, ever-improving overlay-network support listed in OP here, catching up with Bitcoin Core would bring:

  • Multi-wallet support. This is an especially important UX feature for compartmentalizing identities in a privacy coin. (I used to use some shell scripts, originally developed for #2707, to juggle wallets to avoid any possibility that unexpected transparent coins at addresses used to buy ZEC may inadvertently get merged. I gave up on this long ago; I just couldn’t keep all of the wallets synced.)

  • Network-layer/connection manager security protections against eclipse attacks, Erebus attacks, and various other attacks. Bitcoin Core has done much significant work there. (TODO: Gather a list with security research references.)

  • Pruning to help poor people run nodes. (zcash/zcash#4080)

  • New RPCs.

  • Fix and support the REST API (zcash/zcash#2272; see also the bottom of zcash/zcash#2100 (comment). Consumers and retail buyers don’t care about this. For my part, the RPCs are fine. But many business users may want this, for integration with their REST-based software stacks; I believe that is probably why Bitcoin Core has it. I want to expand Zcash use by businesses. The code is already there, and it’s already maintained upstream.

  • Support for the SQLite3 wallet based on output descriptors (which would need a ZIP for shielded support). (Primarily bitcoin/bitcoin#19077.) Adding another wallet database format is worth the technical debt of permanently supporting old BDB wallets for safety of user funds. SQLite is reliable and well-maintained, with no licensing problems for new versions.

  • Numerous bugfixes, and improvements to security, stability, performance, and in some places even—privacy.

  • The major non-consensus-change internal refactoring ongoing for libbitcoinkernel, which is #1 on my Bitcoin Core wish list.

    Lack of any ability to impose hardware-enforced security boundaries between various node functions is a design flaw, of the type that’s not unlikely when one lone-genius inventor was obviously working by himself on a project of large scope. (Transaction malleability was another design flaw, fixed in Bitcoin by Segwit—later otherwise fixed in Zcash.) As a step towards solving this and other problems, Bitcoin Core has tried for years to find a way to refactor a clear boundary between the consensus code and everything else—without risk of breaking everybody’s money. Previous efforts at a libconsensus failed. Carl Dong’s approach with libbitcoinkernel is safe, elegant, and actually happening. Best of all: It will make the core of Bitcoin Core a C library available for other development.

    All of this requires no consensus changes. But the internal code changes are extensive; and Dong designed his plan to facilitate maintainability for much more extensive changes in the future.

    A libzcashkernel delivered as a C library (in terms of API/ABI—thus bindable into most any language) would be awesome for the ecosystem. I can’t want to get my hands on libbitcoinkernel and build things with it; what could be done with an hypothetical libzcashkernel?

  • And, and, and… the list goes on, and on, and on…

That is only a sort of off-the-cuff list, for the sake of illustration. The point is that merging support for v3 onions and other overlay networks is only (IMO) the most urgent part of addressing a general problem.

2 Likes

For the record I arguing that funding the grant in full ($1.8m) would produce more/better outcomes and those saying ZCG can’t afford to fund such a large grant were wrong. ZCG has more then enough funds to fund the grant. Obviously I didn’t explain myself well enough and I apologise for that.

1 Like

Here again as the adult in the room, after almost $700,000 in spending for a few nice pieces of content from 37L we’ve got no material evidence that it was worth the sticker price.

Fewer than 2,500 subscribers on the channel, and barely at 250,000 views. In some parts we’ve also got to point fingers at the fact that they slipped the delivery of the project deep into the market cycle, where people were already racing for the exits.

Tripling down on that sort of bad outcome is a crazy risk to take during a prolonged bear market where mainstream interest in crypto projects is at rock bottom.

I support the revised 1 million dollar proposal by the way. The original 1.8 million dollar proposal is off the table now from what I understand.

I think you’re right. It does appears the $1.8m proposal is a no go. What I don’t understand, and maybe you’re the right person to ask :relaxed:

Why do you support a $1m grant for 6videos, a smaller team, less short content, etc?

If you do support that doesn’t it make sense to also support a $1.8m grant for 12videos, larger team, more short content, etc? For $800,000 extra you not just getting twice as many videos your also getting a dedicated team to produce shorter content which the Zcash community seem to really like.

Maybe my expectations weren’t as high as many others. I think any new channel getting over 100,000 views on their first video is a pretty amazing achievement. The way I see it is if any entity can pull 100,000 views in their first video imagine how many views they can pull after 12.

My opinions on this topic are in the other thread, so lets not bog down Nullius’ context here!

  • 2 separate grants are better than 1
  • (future opportunity) cost per piece of content is quite expensive, in the context of liquidating a ton of ZEC at $60 to pay for it
  • safe to de-risk mission creep by soliciting for a follow-up grant after let’s suppose, the 4th video is delivered in mid 2023
  • let’s also suppose a revived ZEC market where price reclaims $100-150 a coin. Then its much simpler to fund a second grant at $1,000,000 in late 2023
  • think of this bear market as a time to become prison fit not the opposite

To the point about views, those numbers would have been capable for any or every content shop in the world given that they received the full backing, name recognition, and distribution from the entire Zcash ecosystem. I’m not taking away from how great the content and work was, it truly was world-class, but that said the scoreboard paints a different picture.

I’m unsure what the broad question directed to the ZCG is, so i will speak as myself as always.

I would personally be happy to evaluate as many grants as we can get. The ECC funding and dev management as well as the ZF dev funding and management is not under my purview. I do also have a short list of things I do want to see and I think the pipeline will fill in the coming months. I am focused on grants that change things for the entire ecosystem. Top of the wishlist (in no order): hardware wallet UA support, more on ramps / exchange integration, payment channels, frost / multisigs, verifiable credential/public did use on t - addresses, and marketing.

Zcash has the best privacy technology, user adoption is the next big hurdle to cross. Onion v3 support is not what is preventing Uncle Jim and Aunt Susie in Duluth from moving to the Orchard pool.

Marketing has got a terrible wrap in the forum because we all are digital natives, use social media, and the roles do not seem as complicated as a snark security tester or the normal grant roles. Everyone seems to have ideas when it comes to marketing and it is easy to trivialize this work. Please, stop doing this. It’s not productive and insulting to the professionals. It is highly likely people in the forum are not the target audience of some of the content. The goal, in my mind, is to onboard the next million zcash users to improve everyone’s privacy and drive zcash first adoption. By definition these are people who are not using Zcash today and are not in the forums, telegram, twitter threads, discords. Many people still have no idea the biggest hurdle to zcash adoption (trusted setup) is gone. Creating dope memes and yelling “BUY ZEC!” in a tiktok dance to my 4 followers who already know me isn’t the goal of marketing. Finding narratives that tell stories and compel action requires planning, strategy, and talent. That talent costs money and the milestones are harder to define than a fixed scope delivery because user adoption is a really hard problem to solve. I’m glad 37/L has gone through the painful effort of publicly discussing their rates, process, and general strategy. Holding a private company up to the scrutiny of an intelligent and engaged crypto community, in a bear market, is amazingly bold and they have shown the commitment to the cause imho.

There are silicon based problems and carbon based problems with Zcash adoption. The developers and scientists working on the silicon based problems (syncing, tor, frost, consensus, UX) are incredibly smart and talented. The carbon based problems (ie human stuff) are hard because they are not something that can be worked out on a chalkboard with proofs. The skillset needed to make Zcash a “my first coin” will not come directly from a team working on snarks. It will likely come from strangers learning that transparency has more terrifying costs than privacy and discovering a useable coin exists to fill that need. It is in everyone’s best interest that the team that takes on this task is setup for success and represent the communities voice.

4 Likes

The question to ZCG and others was explicit: Shouldn’t a node developer be hired to help get the node up to date, and keep it up to date? I explored that at length, including why “hire more developers” is not a Mythical Man-Month issue here.

As it was originally justified to ZEC buyers (and as I have always supported), the entire purpose of the Founder’s Fee is to pay the people who create Zcash. For otherwise, there is nothing to market. To reply in this thread with off-topic advocacy of expenditure on marketing is putting the cart before the horse, at best.

[Edit before posting: I drafted much of this post yesterday. I missed what happened in 2019–2020, and somehow retconned the Dev Fund onto the Founder’s Fee while forgetting that it was supposed to sunset. Yet another thing that will require much reading to catch up with… If you offer money to the public, you need to understand that people will use it as money. Most users of the U.S. dollar do not follow the twists and vagaries of Fed policy; they never even realize what is being done to their money. That’s one reason why people trust Bitcoin: You can put your BTC into cold storage, go into a coma, wake up years later, and you are absolutely guaranteed that the economic policy of your BTC will not have changed.

Please read this post, and my prior posts, subject to this proviso. I may subsequently change my position based on a better understanding of the situation here.]

I will snip most of this condescending lecture on marketing. I understand very well how marketing works…

…and I don’t need to be insulted with this type of strawman. Creating dope memes and yelling “BUY ZEC!” in a tiktok dance to your 4 followers who already know you would just be more of the low-grade stereotypical altcoin nonsense. Uninteresting. And repulsive.

Here are some actual quotes from private discussions in the past few weeks about my recent posts on this forum, with someone smart and successful to whom I have been futilely advocating ZEC for years:

Good luck lol I am not gonna advocate for something like that

You are advocating to shitcoiners, hard that this will be productive or convince anyone at least in public.

[nullius:] they have hands-down the best technology for on-chain privacy. how could they screw the rest up?

My instincs tend to be more right than wrong

So, why do my Bitcoin maximalist friends have much more money than I do? :thinking: Well, among other things: As I all too painfully know off the top of my head, ZEC is down over 97% against BTC from summer 2017 to summer 2022.

Bye-bye, precious BTC. :crying_cat_face: (For comparison, during this same time period when BTC has outperformed ZEC by about 35x, BTC has outperformed ETH by about 2x–3x.)

Everyone seems to have ideas fantasies about how to capture “the next billion users”. Please, stop doing this. It is entirely dissociated from reality.

Scattered in various posts, I myself have mentioned some growth strategies that are firmly based in reality. I would write more about that, if I were not wasting my time and energy trying to catch up on all the exercises in desperate foot-shooting. (Disclosure: I have some investments in potential near-future Zcash competitors that I believe have better strategic thinking. Business-focused. Not trying to pump to retail moon-chasers on social media.)

Speak for yourself. I am not part of your “we”.

I don’t use social media. None of my tech-savvy, privacy-oriented Bitcoiner friends use social media. With the exception of some public figures such as Snowden, people who care about privacy eschew social media.

Social media are designed to suss out your social graph—some of the most important, intimate information to keep private, together with your financial transaction graph. Simply on grounds of privacy, I would much rather perform in porn and avoid social media than the inverse: It would result in less exposure.

(Aside, one of the reasons why PGP WoT failed is that it exposes your social graph and trust relationships. Advanced PGP users understand privacy; advanced PGP users are the only ones who understand WoT. Thus, WoT was doomed.)

With your condescending and misdirected lectures on the virtues of “marketing”, you are actively alienating planning, strategy, and talent. That’s a shame, when the market suggests that Zcash needs some fresh ideas.


Back on topic:

Forget mass-adoption: You are dismissing the importance of a feature of prime importance in Zcash’s privacy coin niche.

Onion v3 support is a basic checkbox feature for network-layer privacy; to lack it is embarrassing. Zcash has the best blockchain privacy technology, but it is far behind Bitcoin everywhere else—including network-layer privacy. (The Bitcoin ecosystem has even had privacy-protected, user-defined assets for years—far ahead of the belated ZSA implementation—although not on mainnet, and with privacy much inferior to what Zcash could provide. Mostly applied for business use—most retail BTC buyers don’t even know about such things.)

Moreover, your argument comes off as belittling Uncle Jim and Aunt Susie in Duluth—and it is not very respectful of their privacy. Why do you think that they don’t they need Tor?

I am thrilled that Zcash+Tor is being used by geniuses with PhDs from MIT—see the above discussion! Now, what about Uncle Jim and Aunt Susie in Duluth? Don’t they deserve onions, too?

I am guessing that they probably don’t know how to set up AutomapHostsOnResolve (and configure things so that DNS lookups go to Tor’s DNSPort, and…), search for people running Zcash onion v3 nodes (even I didn’t do that!), and manually add custom nodes that zcashd doesn’t know how to gossip.

I would love to get Uncle Jim and Aunt Susie in Duluth onto Tor, and get them using Zcash with Tor. To facilitate this, in one of the other grant proposal threads, I advocated that an ease-of-use node setup grant should stipulate a Tor configuration option as an MVP deliverable.

A point-and-click way for Uncle Jim and Aunt Susie in Duluth to setup Zcash+Tor on a Raspberry Pi would be an appropriate usage for developer funding money. (Not speaking from financial self-interest: I did not apply for that grant, probably won’t, and probably can’t because I refuse KYC.) [See above proviso.]


Word of mouth works. Last month, someone sometimes alleged to be me got into a flamewar with a Monero user over this. The Monero user ended up apologizing for his “fucking trusted setup scam” rant (actual quote, somewhat compressed). That would have been a great moment for bringing Monero users to Zcash—if the Zcash advocate hadn’t had to wind up admitting that Zcash is now chasing the POS fad, and ZEC has unreliable economics. Oh, yes: And Zcash doesn’t support onions. :man_facepalming:

Self-described Bitcoin maximalists who make one little exception for XMR are commonplace. The Bitcoin Forum administrator is known to have some weird affinity for GRIN. Many Bitcoiners care deeply about privacy. Insofar as I can tell, nowadays, those like me with a BTC+ZEC focus are marginal. Ever wonder why?

Anyway, you neatly illustrated here the importance of developers. Despite some relatively small disagreement with their Zcash direction in the past, I always supported the Zcash Company/ECC people because I know they do things like killing off the trusted setup. From watching discussions in GH and this forum, I inferred that they probably hated it as much as I did. I was not surprised when I found out about their work on Halo.

Without development, there is nothing for “marketing”.

2019-1021-16-crop

Thanks for clarifying your ask. No, not by the zcg.

35% of the dev fee goes to Bootstrap to develop and maintain software.( zcashd and operations)
25% goes to ZF (Zebra client and operations)
40% goes to independent parties that bolster ecosystem growth. (the ZCG)

60% of the budget goes to teams that build the products you are saying lack a feature. The remaining 40% shouldn’t also. It should support ecosystem growth, for example through mentorship, coaching, technical resources and/or, creating entrepreneurial opportunities.

In recent past a grant application for multisig wallets in zcasd was rejected in because the ecc was already working on frost. Shielded Multisig (for Halo)

If this is a feature that you think adds value, reach out to the engineering teams at ZF and ECC (via the biweekly Arborist calls or Discord Zcash R&D channel) for their feedback and guidance.

The tor project has themselves submitted for and received a grant for zcg. They have recently reapplied with no mention of adding any functionality to zcashd. I would encourage you to follow up with this grant proposal or submit a pr to the respective dev repo of the client you use.

The zcg grant projects and statuses can be found here: Zcash Community Grants Dashboard - Google Sheets

edit for additional context: i like and use tor. For a some time i maintained docker images for this purpose explicitly (Docker Hub) I may restart this at somepoint, lack of nodes became a problem, and seemingly is worse now. Zcash’s lack of escrow has hindered its adoption on tor services more than addressing imho. I would love it if zcash kept up to date and i hope it gets on the roadmap.

1 Like

The following assumes arguendo the “dev fee”. I never gave my informed consented to the “dev fee” after the first halving sunsetted the Founder’s Fee; and I see that it is falsely advertised as a “dev fee”, when it is largely used for non-development purposes:

This post overall shows a startling lack of understanding of the Zcash ecosystem, from a fiduciary position of responsibility for making decisions on how to spend Other People’s Money.

The only production-quality Zcash full node with a private wallet implementation is zcashd. The subject of discussion here is zcashd.

The entire ecosystem rests on a foundation of zcashd. Without zcashd, there is no ecosystem. (And incidentally, as a practical matter, ZCG’s freebie-ZEC faucet could be switched off with simple code changes in a few files in zcashd. So could all funding streams. Looking at it now. I don’t believe in “governance”. Cypherpunks write code. I know well from Bitcoin that a decentralized cryptocurrency network is governed solely by what code the P2P node operators choose to run. Code is law.)

zcashd is a codefork of Bitcoin Core v0.11.2, a 100% MIT-licensed codebase. Zcash has subsequently merged many of Bitcoin’s later improvements; I do not want to come off as knocking str4d’s hard work on that. (Mostly him; I have seen a number of his merge-from-upstream PRs over the years, and probably missed more.) Nonetheless, zcashd keeps falling further and further behind bitcoind.

str4d’s primary job is to work with daira and ebfull to create the things that make Zcash Zcash. (I here name by Github alias the three ECC team members who wrote the breakthrough paper for the original Halo, later refined into Halo 2; the company has many other employees.) I want for those people focused on what they demonstrably do best—I don’t want to distract them! But to deliver their best R&D work in a competitive product, the node needs to be maintained.

According to you, 35% (not 60%) of the so-called “dev fee” goes to the singular dev team that builds the product that lacks a number of critical checkbox features. Don’t weasel-word “you say lacks a feature”. Do you deny that zcashd lacks support for v3 onions—an important privacy feature!—or my exemplary shortlist of a few of the features that Bitcoin Core has and Zcash doesn’t?

(I am now thinking that ECC really needs a business strategy not based on the “dev fee”, and the “dev fee” should be stopped ASAP per Zcash’s original design; but that is a different discussion, off-topic on this thread.)

Why is it advertised as a “dev fee”?

Not logically connected. A grant application to duplicate functionality that ECC is already building is entirely different than a grant application for node maintenance that ECC has not, in fact, been doing.

Since you say that you “like and use Tor”, I am happy to provide information on how this works.

The functionality missing here is not missing on the Tor side. There is nothing that the Tor Project can do to merge Bitcoin Core’s onion v3 support into zcashd.

If I were to submit an issue to any of the Tor Project’s dev repos about this, that would be bugtracker-spam. It would be impossible to submit a PR, since code changes in Tor Project repos cannot change the code in zcashd. (PR = “Pull Request”; to open a PR requires a git branch with the desired code changes.)

Only a PR in the zcashd repo could fix this. str4d is working on it. I also appropriately opened some issues in the zcashd repo—all for merging in various Bitcoin Core features.

By a close analogy, if zcashd were missing IPv6 support, I could not fix it by inquiring to the IETF, or by filing a PR or a patch to my operating system.

HTH.

1 Like

idk. i dont name things: ZIP 1014: Establishing a Dev Fund for ECC, ZF, and Major Grants

1 Like

For the record, I worked on this backport alone for several months without much of a background in C++, or deep knowledge of either network-stack.

It’s fair to say that I’ve gained a bit of insight into all of the above.

[merge]
   conflictStyle = diff3

This is now in my .gitconfig --^.

Given that experience, and my current appreciation of the scale of the project, I think that this post contains valuable work in the form of enumeration of the necessary tasks, and processes.

A significant challenge I faced was finding collaborators interested in diving into the C++ network stack. If any experienced C++ developers are interested in this project, please reach out to me, I would like to help.

1 Like