I also want to chime in here that it appears there’s already a fairly active Tor network.
ZcashCo operates a Tor introducer node and some “network health” monitoring nodes in Tor-only mode. They see roughly dozens of Tor peers. Additionally there’s a community volunteer, @xyZcash, who’s been operating Tor nodes and taking donations for a long time, and they’ve now received a grant from the Foundation.
There are also several tickets for improvements to Tor and I2P support. I agree with @str4d that a really great step on this front would be a bundled installation that is preconfigured to use Tor or I2P.
The idea is that a computationally weak party can offload the heavy proof generation
for a shielded transaction to a computationally strong party.
This might be most useful when someone has to make many shielded payments.
One major drawback of the current implementation is that for a shielded payment from a z-addr you must give the strong party your spending key to make the transaction.
However for a shielded payment from a t-addr there is no such need.
Also, in the Sapling upgrade exposing the spending key will not be needed for a z-addr either.
SPV support for transparent addresses should be very straight forward. We have begun looking into Electrum support specifically. We’ll post about that if we decide to commit to it.
Yeah, I think it is great idea. I’d love to have some kind of privilege separation so that the private spending keys and the signing are isolated from the network traffic. That way a security vulnerability in the network code that could allow remote attackers to compromise the “node” module wouldn’t necessarily allow the attackers to steal the user’s Zcash.
But, yes, like @bitcartel said, we haven’t actually studied what it would take or made a plan to do it.
This is the kind of thing that would benefit all Bitcoin-family software: Bitcoin-Core, Bitcoin-Cash, Zcash (Magic Bean), Litecoin, etc. Maybe we could collaborate with others on it.
Note that one of our goals for the Sapling upgrade is to make proving efficient enough for mobile wallets, so this should greatly diminish the need for proof offloading. One specific use case where this will remain important is in HSM modules and hardware wallets.
As described here currently the new circuits require around 40 MB of memory and 7 seconds of processing time on a desktop cpu. So this fits the memory profile of smartphones: they routinely have x GB of memory, and 40 MB should not trigger any iOS/Android process watchdogs. At the moment, as far as I know, the circuits have not been benchmarked on ARM yet, so I don’t have any numbers for you there.
What’s the best way to create “sub addresses” for z-addresses?
Right now, I’m giving my z-address to a bunch of people and services to send me z-cash. But if they talk to each other, they can link those payments together. I’d like to give a unique z-addr to each counter party, and have it show up in a single wallet.
I’ve hacked-up this using a custom BIP-44 like derivation, but it’d be nice to have a standardized way to do it. Apologies if this already exists and I haven’t discovered it.
MyEtherWallet has been a massive boon to the usability of Ethereum. What are the major obstacles to producing a similar type of web service for Zcash that fully supports shielded transactions - you already mentioned that using remote proving sending from a z-addr would reveal the spending key and that would be resolved in Sapling are there any other major roadblocks that make it infeasible?
Not really in the sense of trying out things there, because we don’t have anything to do with that project — we don’t maintain that software, do security audits for it, offer user support, etc. On the other hand, we did benefit from the Zclassic chain when it was new because they discovered a problem and reported it to us and it turned out that Zcash software had the same problem, so that was very helpful.
Is Zclassic supported by anyone else anymore? I haven’t heard about it in a while.
As far as I can see, that’s all that would be needed — Sapling (incl. payment offloading). Additionally it would be awesome (but not required) if Trezor, Ledger, and any other hardware wallets would add support for Sapling z-addresses so that you could use a “MyEtherWallet” style wallet with hardware protection for your spending key.
I think the Zen team oversees Zclassic but I’m not very sure about the details. I just figured it could be used as a last tier testnet for changes to Zcash since i dont hear much about development.
How will this work? Don’t we need to scan the whole blockchain to get the balance of a new address? My understanding is that the reason it works for Ether is because Ether stores state (and not UTXOs). Since z-cash stores UTXOs (for both t-addrs and z-addrs?), even simple operations like getBalance etc… will need to rescan the whole blockchain, which will be very expensive.
Won’t we need to build an electrum-style caching server that stores the balances and indexes UTXOs for all addresses?
I’d certainly be happy if they would deploy upgrades that we’re working on and notify us of what they learn. To facilitate that kind of thing is why we’ve gone ahead and open-sourced all of our work — including the Sapling implementation that we’ve done so far (even though from a “zero-sum competitive” mindset, that is risking that our “competitors” get to use our work ahead of us).
I don’t expect them to do so, though. That’s a lot of work! And I haven’t heard from anyone that they are focusing on that. But maybe they’re going to surprise us.
