Is there a plan to split the zcash daemon into a client (that has the wallet, keys, transaction creation etc…) and a server (with the blocks)? I’d love to run one server and have multiple users connect to it.
There is an implementation that is still being reviewed and not merged https://github.com/zcash/zcash/pull/2143.
The idea is that it lets you store only a viewing key, enabling you to track incoming transactions to a z-addr, but not to spend from it.
This is useful, e.g. when you want to store the spending key only in offline storage for extra security.
We have no plans to co-operate with the Cosmos network to build this. I’m actually not very familiar with how Cosmos hubs work, but couldn’t hash time-locks be used to lock funds for transparent addresses? We currently do not have opcode functionality for shielded addresses and are not planning on adding that in the immediate future.
The more general purpose the functionality, the more open we would be to adding it. If you’re interested in a feature like this, please feel free to start a discussion by opening an issue on our github repo describing the details of how it would work.
I don’t understand the Cosmos technology, but I love the idea of cross-network interoperation in general. (Hence https://z.cash/blog/htlc-bip.html, https://z.cash/blog/project-alchemy.html, There are three different flavors of “Project Alchemy”, https://github.com/ethereum/EIPs/issues/152, etc.)
I’m not sure how to proceed. Maybe someone who understands the Cosmos technology could create some kind of prototype of this and demo it on a hangout-on-air?
@adityapk00 That’s a good idea but we haven’t spent any time looking into this. Of course, btcd has already done this and I think in the long run, cryptocurrency software will become much more modular than it is today. Please file a Github ticket to help the community keep track of this long-term goal. Thanks.
Is there a simple overview of the payment offloading feature that is coming soon. What are the potential use-cases enabled by this technology and as importantly what are the major drawbacks of it?
edited, sorry I think it is called remote proving service?
Thanks for doing this AMA.
I remember reading about a plan where a client could offload joinsplit creation to a different server? Is this still on the roadmap? Or will the new circuits’ performance be good enough to run on phones and other less powerful devices?
I would like to see (optional) end-to-end encryption between nodes, whether BIP 151 or something else.
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.
Ok, sounds good, thank you! I will keep this in mind. I might be able to do something like this in January
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.
You can find a list of Zcash nodes to connect to over Tor in this thread: Zcash addnode Tor hidden service .onion
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.
Any idea how less straightforward it is to support z-addrs? t-addrs do seem easy AFAIK, but given https://z.cash/blog/new-research-on-shielded-ecosystem.html it feels like another wallet that only supports t-addrs wouldn’t be that useful.
Wowza. That’s amazing. Can’t wait to try and run it on my iPhone.
We’re excited about this too!