Well folks.. it’s here! Zingo 2.0 available in Apple and Google app stores. Check it out, and keep an eye on this thread to hear all about this comprehensive upgrade!
25 Likes
I like the “Danger zone” and the new transparent address option!
6 Likes
The Turkish translation looks great. More people in Turkey will use Zingo, and in their own language too!
Thanks for the collaboration.
6 Likes
Zingo! Wallet 2.0.0 is here! This version gives you more control over your funds, greater privacy with Tor, and new ways to organize your shielded addresses.
Now with Pepper Sync 2.0, you can spend even before sync completes—without sacrificing clarity or security.
It also includes minimal confirmations, visual enhancements, and Turkish language support.
Here’s everything that’s new 
Update 2.0.0
11 Likes
Thanks @markoosh!
Here is some of the thinking we put into this feature.
What’s Safety?
In the Rust programming language source code is “Safe” by default which means that the compiler guarantees that certain problems (with resource allocation) cannot occur.
If you can convince a Rust compiler to compile your source code, then you know that it doesn’t have certain kinds of bugs! It so happens that the kinds of bugs that you can’t have are some of the most important sources of security vulnerabilities in other languages.
Now.. sometimes you might want to write a program that does something that is risky. You understand what needs to happen, and you can write the code in a “safe” way, but the guaranteed safety that comes from the Rust compiler has to be switched off in a specific location, so that you can execute the risky but necessary operations you need for your Use case. To do what you need to do, you have to mark the risky code specifically as “Unsafe”.
How Zingo 2.0 Approaches Safe Taddresses
This is the philosophy that the Zingo 2.0 interface used to approach taddresses.
Zingo 2.0 is private by default it does not allow a user to offer a taddress to a sender. This is because (as in Rust) taddresses allow dangerous information leakage, and are a potential important source of security vulnerabilities.
But (as in Rust) you might know that you do need to offer a taddress for your use case. To do so in Zingo 2.0, you must turn off the “private by default” behavior of the application-in-service, and enter “The Danger Zone”, analogous to entering an “unsafe” block of Rust code. In that context you can access your taddress, or generate a new (single use?!) one.
We think this the correct pattern for dealing with dangerous, but important, functionality. The application-in-service (Zingo 2.0) has only enough authority to enforce private-by-default behavior if that’s what the User requires.
Recommendation For Safe Operation
To minimize the danger from leaky taddress use, Zingo2.0 offers a convenient taddress generation feature, so that each use of a taddress can produce a unique taddress that’s uncorrelated to any other revelations.
This is a feature that was specifically requested by @frankbraun in this blog post in which he correctly (in my opinion) highlights the integration role of taddresses.
If you must expose a dangerous taddress, please generate a single use taddress uses the “New Address” button offered by Zingo 2.0.
9 Likes
Reasoning About Agentic Applications
It’s increasingly the case that applications are “agentic”, able to pursue goals without human intervention. We think about this when we’re attempting to design tools to enhance autonomy and dignity.
To contextualize our thinking and inform our design decisions, we turn to the principles expounded at erights.org. For this release of Zingo 2.0 we paid particular attention to The Principle Of Least Authority.
We chose to allow the application sufficient authority to generate new addresses, but we did not delegate the capability of choosing to do so to the app, rather we reserved that capability for the User. We think that allowing the app to automatically generate addresses provides it with more than the Least Authority it requires.
Our design requires User Consent, for operations we believe that the User has sufficient capability to make.
As we have reasoned about this internally, we developed a term of art, The Application in Service (AIS), to clarify how we think the Application should relate to the User.
5 Likes
Interesting design choice, I like it.
I just tested it and if you don’t mind, here are some additional suggestions, based on my understanding that you want to give the most authority to the user and let him make explicit decisions, rather than having things done automatically for him:
- If a t-address has already been used I would show a warning on the screen where it is shown and advise the user to generate a new one, to prevent linking two transparent transactions together by reusing the t-address.
- If a user has received funds on two (or more) different t-addresses shielding them will link them together. If you want to give the user explicit choice you could warn him about the the linking and offer him a choice to just shield one of them (to prevent linking).
- It might also be a good idea to show the amount of time that has elapsed since the last shielding operation (to make timing attacks harder).
- Maybe you can even show the number of transactions that happened on chain since the last shielding transaction, if you have an easy way to query that from the backend. To give the user a better estimation if enough time has elapsed since the last shielding transaction to make timing attacks harder.
- Funds received in multiple transactions on the same t-address can and should always be shielded together. They are linked anyway, so nothing can be gained anymore by shielding them separately.
In this post I describe a similar possible mechanism for Zashi, but with a UX where most decisions are made automatically for the user:
4 Likes
This is fantastic feedback! Thanks very much.
Perhaps we could have our cake and eat it too, so to speak, by letting the user opt in to these behaviors as a policy, so that don’t have to manually specify each behavior every time.
3 Likes
You’re welcome. Advancing to the next unused t-address is pretty standard in Bitcoin wallets, so I would definitely consider that, I don’t think you gain anything by having the user do that manually. The user can still manually retrieve old addresses, if he wishes to do so, and in that case I would warn him about linkability.
I’ll think a bit more about “shielding policies”.
