Does ZingoLabs still aim for a self-sustaining application that aligns ZEC user and developer incentives?! Yes! That’s the plan… where we’re heading…
Is it within the scope of this grant? No!
Since we began work on our vision for a sustainable, reliable, intuitive user-facing zcash app… it has become clear to us that the environment is more dynamic than anticipated!
Which is exciting! But, is also a strong signal that we should focus on components that will certainly be relevant now, and push them to a state of completion before scheduling the next set of tasks.
We have a great deal of uncertainty about the transaction volume (in any pool) going forward. We’re aware of rapid development on zcashd, and zebrad, and warp-sync.
It’s not clear how those variables (transaction-volume and transaction-state) will change moving forward.
Therefore we’re staying focused on our Orchard implementation.
How do we fit into the wider economy?
our Orchard/Wallet implementation aims for portability, so we will be efficient at porting our solution to wallets
we’re refactoring our code to ease building against WASM for web-based applications free2z/ZUUL
we’re opening PRs against librustzcash and orchard
we’re providing test tools to facilitate lightwalletd-proxy testing
Update, we did indeed complete our Milestone 1 on schedule.
After some internal discussion, we intend to pull the current grant and reapply with specific amendments to address the concerns raised by the ZCG in their last meeting.
In response to questions raised here, ZingoLabs is ammending its grant proposal in the following ways:
smaller ask: $128_520.00. This substantially smaller asks reflects three changes:
1. Fewer applicants. Now there are 3 of us (Za, Juanky, Gygaxis)! One of our members has unanticipated obligations that won't allow them to participate in _this grant_ as an applicant.
2. Recalibration of the hourly rate relative to Earthrise's Successful Grant Application.
3. Shortened backpay interval to the minimum necessary to cover our living expenses.
niche specification:
1. reliability: multiple key holders
2. economically aligned: our strategy is to produce transaction mechanisms that:
* allow us to sustain our efforts
* explore the space of consensual economics
3. user-engaged: our first experiments will be in the space of minimizing user-to-developer friction
4. reuseable code: our SDK will have more tests, documentation, and cleaner APIs than others
Target Userbase people who want a reliable - responsive mobile app:
reliable because we are building our livelihoods on it
responsive because we are providing options that connect User Asks with Developer Agency
Finally, we’ll note that we’ve hit our first milestone, and are much more familiar with the codebase.
Should the last address option instead be “U-Unified”? If in the future, when Zingo decides to be an Orchard-focused wallet, then users can easily migrate their keys while keeping access to their balance.
Anyway, I want to express my support for this grant to be approved. Cheers!
Yes, it should be Unified. The unified addresses are currently orchard-only, we intend to rework that after we finish getting spending from the orchard pool working, so the names and interface there are a bit of a placeholder at the moment as they will need to be restructured anyway if we want to support the full set of possible UA combinations.
Ideally unified addresses will be the only kind of address that’s readily available. You could then provide a second-level UI to obtain the transparent or Sapling components of the UA for use with legacy UI that don’t yet recognize UAs, but for the top level address, I don’t think you should have tabs at all.
This wallet seems to be a fork of ZecWallet Mobile. So it replicates the implementation of Orchard and misuse of Unified Addresses.
Please note that Unified Addresses should be the only address users should share with the option of decomposing the receivers for recipients that can’t receive UAs (until they do).
Using a UA-Encoded Orchard address should be considered an “anti-pattern” of Unified Addresses. UAs should be favored before any other kind of string encoded Addresses because they are a “Multi-Pool Wallet Management” Pattern that allows the users to delegate knowledge of pools and addresses to wallets and so that users only handle one type of address like all the other cryptocurrencies do (except XMR that has Master and common addresses and Zcash forks that have T and Z). This makes the protocol more flexible at the user end and provides not only the possibility for Protocol Developers to add new pools with their respective addresses, but to retire them as well.
Zingo and ZecWallet should show the UA with Transparent, Sapling and Orchard receivers and then have a second screen that de-aggregates Transparent and Sapling for compatibility reasons
EDIT: please don’t think of this as an “error” on your behalf. We should have had better documentations so developers didn’t have to figure it out by themselves.
We’ve been deferring thinking too hard about the interface changes we’ll need to make until spending from the orchard pool is implemented, but this does sound like the ideal interface. The third milestone already includes reworking our UA interface so that we support all valid receiver combinations, this would be a simpler way of doing that than keeping all the legacy address code in there adjacent to the UAs anyway.
Edit: After discussion with @zancas, we would be happy to change milestone 3 to expicitly include a switch to this interface.
While I understand the desire to build a UI that supports future protocols, I feel that it hardly makes any difference today.
ZWL shows:
T
Z
O as UA
I think that you suggest:
T+Z+O as UA
T
Z
Besides the order, the second UA has T & Z receivers. However, any wallet that understands how to decode a UA would use the O receiver until the next pool, wouldn’t it?
If so, when would the T & Z receivers be used?
It is entirely possible (and an easier lift) for wallets to implement Unified Address decoding before implementing send-to-Orchard support. UAs that only contain Orchard receivers cannot interact with these wallets.
Example: exchanges that currently only allow withdrawals to transparent addresses, can and should allow withdrawals to UAs containing transparent receivers. This has the added benefit of being able to measure how many of their users would withdraw to shielded if they could, which is a metric they can use as part of deciding whether to add shielded withdrawals to their engineering roadmap.
If the sender’s wallet has sufficient funds in the Sapling pool to create a transaction, then if the receiver’s UA contains both Sapling and Orchard receivers (i.e. the receiver is indicating their preference to receive funds into either of these pools), the sender’s wallet can create a fully-shielded Sapling-to-Sapling transaction instead of an amount-visible Sapling-to-Orchard transaction.
It seems to me that implementing t2z is of the same complexity as t2t because the builder takes care of everything. Therefore, IMO, if an exchange has decided to not withdraw to shielded, I don’t think it is because of engineering reasons.
Likewise for transparent wallets, I think they chose to stick with a simple model and to let the recipient deal with shielded addresses themselves. In other words, I am not sure a transparent-only wallet will update to support UA because of the confusion it will cause to their users.
Thanks. Is there a design/specification document describing the expected behavior? I could only find mentions of “shielded by default”, which can mean many different things.
This is (sadly) false - or rather, it assumes the use of the Rust transaction builder (which I’d love everyone to be using, but alas).
t2t can and is done in a variety of languages and platforms (because it is generally built on top of whatever language / platform was already being used for Bitcoin), while t2z currently requires Rust (because that’s the language in which the proving system and circuit are implemented in).
Now, the Rust components can in theory be used anywhere that supports C FFI. However, integrating Rust components into an exchange’s (likely custom in-house) transaction builder implementation can be a significant engineering lift for teams that don’t have Rust experience. Guess how I know
ZIP 316 describes how Unified Addresses must be interpreted by consumers of them.
The protocol specification and relevant ZIPs describe how transactions must be constructed.
Beyond that, there is no specification document for how to send funds because there’s nothing else normative to specify: wallets get to decide what behaviour they implement that best serves their users’ interests. However, “ZIP 315: Best Practices for Wallet Implementations” (in-progress draft) is where we intend to provide general guidance on how wallets should construct transactions.
@hanh note str4d’s comment about ZIP 315 being in progress. Given our focus on UX, we’ll want to review this in terms of general UX best practices before publishing so it’s subject to revision.
