Z.cash website looks much better.
7 Likes
Iâm replying strictly to share what the current plans are regarding the ECC wallet. The primary driver behind having a wallet is to test and demonstrate the features and functionality that we are building in the SDK. Essentially a âtest bedâ - although I hate to use that term as it implies the wallet is not production quality. The UI is simple, black and white, basic interface. The concept is a blank slate.
There are enough other wallets out there with various bells and whistles to suit any of the technical appetites⌠but for someone who wants a simple straightforward app, then youâll have another choice. This also factored into ensuring that we didnât commit resources beyond that which is necessary to deliver the basic app. The focus has been to get functionality in place to allow fast spending of available funds and end what we have referred to as âEmergency Modeâ. Delivering the functionality through the SDK (with zcash 4.6.0 and lightwalletd 0.4.14 minimum supporting it) will allow any other app using our SDK to take advantage of both the sync efficiency performance gains as well as the fast fund availability components.
4 Likes
Undoubtedly, a substantial number of individuals are eagerly anticipating the release of the ECC wallet. Consequently, I would like to know whether you intend to offer a demonstration of the aforementioned wallet during the Zcon event?
1 Like
Is the SDK in Rust. Would I be able to build a wallet using this? I mean I use YWallet but havenât really read the code internals as I donât have the time. However, if this SDK makes it easier to interact with the blockchain I might build the user interface to the wallet myself since ECC is not building the user interface? I know we have a lot of other teams doing it but doesnât hurt to have another I guess. Also will use https://tauri.app/ instead of Electron.
2 Likes
librustzcash is in Rust and has light client tooling. The android sdk and secant wallet are in kotlin and ios in swift. A lightwallet dev might know better about a more exact answer
1 Like
Is there a light client in rust. I would hate to use ios/android specific tooling. I mean it would make sense to have a really good client in rust since the chain is written in rust. Almost everything is written in rust. Basically what repo would I need to look at to work with it. I guess I can look at what zcashwalletlite and ywallet use.
2 Likes
Zingo is in Rust (sry, forgot for a sec 
)
2 Likes
The SDKs were originally built in Kotlin and Swift to make it easy for iOS and Android devs to build apps on top of Zcash. They both leverage librustzcash for chain access. If youâre building a Rust based wallet librustzcash should give you everything you need.
2 Likes
- Ensure ZEC, self-custody, and staking remain viable in the USA through focused policy work
I am perplexed that in spite of the ongoing funding insecurities, ECC is retaining political lobbying as a core initiative. If research and development is what ECC is best at, then why continue to burn money lobbying transient C-league American politicians?
Considering that the lobbying activities have a long history now, can I ask if the ECC can provide any tangible demonstration of positive results?
The complete disconnect between American political lobbying vs Research and Development of cryptographic blockchain features has me wondering if Zcash wouldnât be best served by the ECC being divided into two wholly separate entities.
- An American Political Lobbying PAC for blockchain privacy, cryptocurrency assets, et al
- The Electric Coin Company, a Research and Development organization that supports Zcash
By separating these two absolutely different pillars of work, and their costs/ planning/ staffing et al, the Zcash ecosystem can more efficiently allocate block rewards to one versus the other. Letâs hypothetically speaking, imagine the post-halving block reward granting 2% to the American Political Lobbying PAC, and 4% to the R&D ECC.
2 Likes
i think u got point there. more decentralization is only good.
and ECC could focus only on development.
Hi @noamchom.
We have a lot of deep history and experience here, and have given it a lot of thought. As Iâve stated elsewhere, some of this I can discuss in detail, some I canât. I encourage you to watch Paul Brignerâs presentation at Zcon4 and the panel heâll moderate. If you are going to be there, engage with him and me while we are there.
To your question, perhaps the most significant demonstration is that there has not been an unwarranted or rash enforcement actions. Paul, myself and some others have met both formally and informally with members and orgs across DC including the SEC, OFAC, FinCEN, the DOJ and the White House. In spite of some key differences of opinion, we have built many strong relationships that have yielded important bi-directional information sharing. Itâs important to understand how DC works, and that it takes years to build the right relationships and trust, so that when issues arise, there is a trusted relationship already established and able to speak truth. Itâs not a light switch that is simply turned on. There is a reason that Zcash is not vilified, as others are, among the key voices in DC.
Additionally, we have had off the record briefings and conversations with a number of politicians and their staffers about privacy and the importance of Zcash for financial freedom, addressing their questions and concerns. Current congressman and Senators include Emmer, Davidson, Lummis, Sessions and others. Congressman Davidson in particular is very knowledgable about Zcash and a huge proponent of protecting our financial privacy - I sat next to him at a dinner we hosted and he DMâd me right after with personal contact details. Emmer and his staff have been actively communicating that âPrivacy is Normal,â an ECC narrative push. A huge win.
We recently held a briefing at the US Capitol building, sponsored by Tom Emmerâs office. It was focused on financial privacy in crypt filled with staffers and influencers. There was standing room only. It included a keynote by Lizzy Fallon, on Emmerâs staff and the Financial Services Policy Director at U.S. House of Representatives and JW, from the ZF Board of Directors. I gave a presentation on Zcash and the importance of digital cash. Will it make a difference? I think so. One step at a time, but that was a big one. Very few can make this happen.
We have been working with others, predominately the Blockchain Association. We created and they help sponsor the monthly PGP for Crypto breakfast at Georgetown University. Itâs invite only and attended by the whoâs who of policy and regulatory influencers in the space. We had to recently cut back the invite list because it was getting too large. Paul runs and MCs it, and itâs been the launching pad for the aforementioned briefing and PGP podcast series.
With many orgs in DC, their attention is divided and there are many in crypto who are quick to throw privacy under the bus in order to win regulatory favor for their project. We are the beacon. Weâre also focusing on self-custody and PoS based on ECCâs work.
Net, we have an established strategy and have built an outsized ability to engage based on years of positive relationships and trust.
Whether that should continue to be at ECC or split out is a valid question. The pros for keeping it at ECC include the established brand that has been built in DC, the irreplaceable relationships we built, and cost, as we are able to provide stable employment with an established entity. The cons, as I see it, is that we canât lobby given ECCâs 501(c)3 status under Bootstrap, and we can no longer afford to engage internationally.
10 Likes
Since ECC announced their restructuring Iâve been thinking about what Iâd recommend to the community in terms of structure for taking over responsibilities. This will obviously change depending on which use cases ECC intends to keep supporting and which they donât, but here are some thoughts:
- Protocol upgrades: Establish a pipeline for making protocol upgrades through ZCG without relying on ECC. The general format of a grant would be (a) protocol design, (b) design security review by an audit firm, (c) implementation in zcashd and zebra, (d) security review of the implementations, (e) getting PRs against zcashd and zebra merged.
- A risk is that security bugs can be really subtle, and merging protocol changes without review by ECC core team feels dangerous to me. Audits can help, but in some cases there is no substitute for review by people who are intimately familiar with the protocol.
- zcashd: Invest in the zebra+lightwalletd+lightwallet stack as the âofficialâ recommended way to run a full node, e.g. for miners and exchanges, and consider zcashd deprecated. Miners and exchanges rely on certain zcashd wallet APIs, so this means we need to fund adding those features to zebra or build adequate (i.e. extremely reliable) replacements in a light wallet. Once almost everyone is on the new stack, ECC can fully deprecate zcashd, start contributing to zebra, and the âzcashd implementationâ part of the protocol upgrade path above can be deleted.
- Security: For community projects, we can fund a âsecurity coordinatorâ to assess bug reports across all projects. This way project developers are shielded from some of the noise that comes in through security bug reports, and all projects automatically have a security response program.
- I think this should be backed up by a team of developers who can actually go in and make changes to community projects, in case those projectsâ authors are AWOL or too busy to make the fixes.
- Core protocol security should, I think, still be owned and shared between ECC and ZF. Certain types of bugs need to be kept secret while fixes are developed and ECC and ZF have proven themselves to be trustworthy in that regard.
- Projects should of course still be audited, e.g. through a grant like my own or by making security audits part of the grants themselves or done through companion RFPs.
- Alliances and exchange support: It would be helpful to have more information from ECC on what this actually looks like in terms of day-to-day activities and workload.
- Whatever this ends up looking like, it needs to be tied closely to the security functions of ECC/ZF and the community. Reaching out to partners in a timely manner is essential in big security responses.
- Global regulatory relations: This is way outside my area of expertise, so I have no ideas.
- Digital properties: Sounds like ECC has some plans for these in the works.
- Product marketing: Iâm hopeful that Shielded Labsâ User Adoption Working Group will be able to bring forth some good marketing ideas.
- PR and media engagement: Also outside my area of expertise, but it sounds like this could overlap with partner outreach and even security coordination. Maybe a new team of a couple bizdev people and a few engineers could take on all of security coordination, PR/media, and partner support.
12 Likes
It sounds like you want to make a desktop light wallet with rust and tauri?
That could become a really valuable app, IMO! Iâd definitely love to try it out.
Please let us know how we can improve the rust APIs, especially around documentation. Feel free to liberally open tickets on github with questions/bugs/suggestions.
Keep in mind, our product priority has been focused on the mobile SDKs as the primary developer product, so the rust APIs may need better documentation or other improvements.
4 Likes
I am not yet familiar with Rust, so I will be learning it as I go along. However, I have considerable experience in UI design, particularly with Svelte, and I believe that Tauri shouldnât be too difficult for me to pick up. This isnât my first time delving into the task of learning new programming languages.
For the stack that ECC maintains:
- Everything that the Android and iOS mobile SDKs use is available directly in Rust via the
zcash_client_backendandzcash_client_sqlitecrates (source here). - The
zcash_client_backendcrate provides a Rust gRPC client that can talk tolightwalletd(the mobile SDKs instead use Kotlin and Swift clients respectively, to maintain unified network stacks).
So it is possible to use those crate APIs to implement a pure Rust light client. I personally have a very-much-not-production-quality Rust CLI wallet app built using these crates (for the purpose of testing them).
What is missing is a âsimple Rust wrapperâ that pulls together the zcash_client_backend and zcash_client_sqlite APIs, calling them in the right order and hiding the complexity behind a single unified âlight client walletâ object. The Android and iOS mobile SDKs have the concept of a Synchronizer that fills this role. Implementing something like this in Rust would be a nice unit of work; itâs also something that is likely to evolve naturally within the zcash_client_backend crate as we move away from the âstatelessâ API design we currently have (originally designed for ease of usage by the mobile SDKs across FFI) towards a âstatefulâ API design that maintains ongoing state in Rust-allocated memory (necessary for DAGSync).
3 Likes
So DAGSync works by establishing a stateful API design?
Would I be able to utilize DAGSync by some function I invoke in
Or would I need to implement that?
I guess I will learn more as a dive deep into docs, code and papers on how this works. DAGSync would be a very important part as syncing is the biggest issue right now for wallets.
Could we move this discussion to the Zcash R&D discord? Seems like it would be a better platform for such a technical back and forth not related to the roadmap!
(this highlights another subtle issue with Zcash - no one knows what the official discord is and there is little to no official discord moderation or presence).
2 Likes
I was wondering when someone would say something. Doesnât have to be discord. I know a lot of people that donât like the real time nature of discord. So I created another thread: [Zero] Updates on ZEC only wallet. Actually, Discord works great too.
1 Like
No; the stateful design is just a consequence of needing an in-memory representation of the wallet that persists beyond a single FFI call (which is what the current APIs are designed for). You can read more about DAGSync here: DAGSync: Graph-aware Zcash wallets
DAGSync is not fully implemented yet, and wonât be for some time. What we have been working on for many months now are the first few components of it:
- A significant amount of preparatory engineering work to enable the
zcash_client_backendandzcash_client_sqliteto cope with non-linear scanning.- As a side effect of this, linear scanning is now significantly faster.
- Building the
shardtreecrate and making changes to note witness management, to enable notes to be spent almost as soon as they are received.
The upcoming zcash_client_backend 0.10 and zcash_client_sqlite 0.8 crate releases will have the new and updated APIs that enable this. They are part of items 1 and 3 in the ECC roadmap.
Happy to answer further questions in the R&D Discord, but I kept this answer here as it is relevant to the posted roadmap. (Mods will move these posts to a separate thread if they disagree.)
3 Likes
This forum is best because it is publicly viewable, and relatively easily searched. Discord is gate kept by a user name page and doesnât look as well suited to function as a discussions archive.
I do agree that the technical spinoff topic needed its own thread.
4 Likes