Zingo! Onward

[refinance]

You are not considering being self-funded by micro-transactions anymore?

[zancas]

That’s our intention. We need to implement-or-integrate several new technologies to get there.

TL;DR We need to see what we’ve got to spend it well.

A key component of micro-transaction funding is a suitable recipient for such funds. We think having finsight into the state of that recipient will be essential to efficiently leveraging those funds…

We need to know not just the size of our treasury but also where it’s coming from and where its going. The right answer for this kind of problem is tooling. More specifically we need intelligent representations of our treasury to make well-informed decisions.

TL;DR We need distributed spend authority to spend it well.

Beyond knowing what we have we need a mechanism to collaborate in the spend process. For that we hope to leverage the shielded threshold signature capabilities that the ZF is working on.

[geffen]

Morning! Is there a place to see progress or even just screenshots? I’m sure everyone would like an update, but I’d specifically like to see how you guys handled the insight/advanced finsight and memo threads. Thanks.

I understand this thread is a bit stale, please direct me if I am in the wrong place.

[JoakimEQ]

Here is an update Zingo Lab Viridian Isn't Hitting Finsight Milestone Two - #3 by JoakimEQ

[zancas]

I am writing to provide the community with an update on the ZingoLabs effort.

Our February 6, 2023 Authentic Financial Insights proposal is not the best way to organize our immediate efforts.

We have been hard at work on three complementary efforts, that are necessary to provide users what they need in the immediate term.

Speed, Reliability, and Privacy.

To get Zingo to run faster:

We have been experimenting with a port of the latest version of the ECC’s witness handling API. To verify that the new version of zingolib is both faster, and still correct, we’ve done extensive user-testing with communities around the world. We discovered that occasionally under unreliable network conditions, on certain architectures, the new version (which is faster) fails to correctly mark notes as spent. As a user facing application that intends to be broadly available this is unacceptable to us.

This has stimulated us to build out our test infrastructure…

To get Zingo to run more reliably:

We now test end-to-end, on multiple architectures, against a range of simulated network conditions, and block-chain scenarios. To do so effectively, we’ve invested significant development into the darksidewalletd framework, network-proxy tools, end-to-end tests on emulated devices, and increasingly into unit-test frameworks. In the course of this work, we have investigated network privacy tools which has led us to collaborate on the Nym project…

To get Zingo to run more privately.

We are currently researching how the UA format can be extended to support Nym addresses, and how Zingo can become a Nym client. We are also considering whether and how our new ground-up Rust proxy will relate to Nym PEAPPs.

Because this work is not directly producing User-Facing Finsight features, we have foregone the earmarked milestone payout.

We will be releasing a faster version of Zingo, in the near future.

Once it is released we will petition the ZCG to consider paying us for the enhanced performance of Zingo, the community-available tools, and the contributions to ecosystem projects we’ve made:

• librustzcash/ECC
• ledger/ZonDax
• nym/NymTech

TL;DR our current work is focused on:

• porting the latest ECC sync SDK, to increase sync speed
• extending our tool kit to cover a much broader set of conditions in multiple dimensions
• supporting ZonDax ledger integration (on desktop Zingo-PC)
• extending the UA format to support Nym addresses
• extending our network stack to run over Nym
• incrementally replacing lightwalletd/darksidewalletd with a pure Rust wallet-proxy
• implementing and end-user error report button (for experts) to push scrubbed data to us, in error cases

[zancas]

Hi folks! The faster version of zingo I promised above is now here:

ShardTree Zingo! 1.3.0

Folks, it gives me great pleasure to announce Zingo! 1.3.0 is released. This release uses the ShardTree note commitment store to enable rapid witness updates. To end users this means a long awaited increase in sync performance. In addition to the core upgrade, we added 40% more tests of three different types, and onboarded more developers. We’ll be releasing again soon!

We’re going to ask the ZCG to provide us the repurposed Finsight Milestone 2 payout for this user-affecting update!

[zancas]

Look forward to another release soon!

[zancas]

Hi @ZcashGrants, @hanh, @noamchom, @Lukas, @Honza , @nuttycom, @harryhalpin

ZingoLabs is proposing the following feature list as a replacement for the old MileStone 3 commitment:

• ZIP317
• Android Background Sync in Android Mobile Devices
• iOS Background Sync in iOS Mobile Devices
• an upgraded Basic (Even More Basic) Mode to facilitate new User on-board
• regtest mode implementation in zebrad to facilitate deprecation of zcashd
• new wallet UI, and streamlining to integrate Nym privacy into the wallet (this does NOT include necessary work on the server-side, or Rust library components, which must be funded by other sources)
• coordinated work with the Zcash Foundation to produce a pure Rust, backwards compatible alternative to zcash/lightwalletd

We intend to complete this work by April 5th, 2024.

[aquietinvestor]

Noted. We will discuss and follow up with you next week. Here’s the detail of the old Milestone 3 you want to replace:

Milestone 3: Out Of Order Note Update, Spend Before Sync, ZIP317

1. The User benefits from the latest innovations available in librustzcash to have a faster, and smoother experience when sending and receiving funds from the mobile, desktop, and command line apps.

2. ZingoLabs manages proxy infrastructure to enable more flexible and thorough test

Qualitatively success can be measured in increases in well-informed and thoughtful decisions made by Zingo users.

[hanh]

The original milestone looks pretty good to me. Could you elaborate on the reasons behind the replacement?

[kworks]

coordinated work with the Zcash Foundation to produce a pure Rust, backwards compatible alternative to zcash/lightwalletd

Could you explain this a bit more?
Thanks

[zancas]

Good question! The work that is not covered in the new list, that was in the old is the core sync upgrades. We’re pushing two of those out past BackGround Sync:

1. Out of Order Update
2. Spend Before Sync

TL;DR: We’re going to ship the core sync upgrades next, but first BackGround Sync.

Why? Because Background Sync is faster, safer, and has better impact on UX.
It also augments the core work. Both the ShardTree port that we’ve finished and the new features that we’re developing get time to run!

BackGround Sync:
(1) Faster to implement
(2) Safer to implement
(3) Has at least as much impact on UX
(4) augments the effect of the work on the core algorithms

Per the other items on the list:

UI:
UI needs to respond to User experience by becoming simpler, and prepare for new security enhancements.

• an upgraded Basic (Even More Basic) Mode to facilitate new User on-board
• new wallet UI, and streamlining to integrate Nym privacy into the wallet (this does NOT include necessary work on the server-side, or Rust library components, which must be funded by other sources)

Infrastructure:
We can’t run on a house of cards. This work moves us toward a pure Rust future, and benefits the entire community.
1 regtest mode implementation in zebrad to facilitate deprecation of zcashd
2 coordinated work with the Zcash Foundation to produce a pure Rust, backwards compatible alternative to zcash/lightwalletd

Per coordination with ZF, we haven’t heard anything from them yet. We don’t really know what the solution will look like, but we’re committed to making it happen.

[hanh]

It takes 25 minutes to synchronize 2 months of data (using the improved Shard Tree, on the Samsung S24 Ultra). Per @joshs post, Zashi should take ~2 minutes. Therefore, I hope it won’t take too long before the synchronization algorithm gets updated.

[aquietinvestor]

@zancas

new wallet UI, and streamlining to integrate Nym privacy into the wallet (this does NOT include necessary work on the server-side, or Rust library components, which must be funded by other sources)

Hi @zancas. We have a meeting on Monday to discuss the milestone changes you proposed above. Regarding the Nym integration, can you elaborate on what’s included in Milestone #3? Thanks!

[zancas]

Hi @aquietinvestor a significant part of the Nym integration is proper UX.

We’ll propose several possibilities via experimental releases (i.e. TestFlight in Apple, internal test in Google) that provide sample interfaces, that aren’t connected to Nym, to solicit user feedback on the preferred experience.

Implementation of Nym integration will continue to proceed separately, and won’t be covered by funding in this MileStone.

[zancas]

I really appreciate this data!

Based on this, I think that if Back Ground Sync runs for 10 minutes/day, then Zingo is syncing ~24 days per day of Back Ground Sync.

I agree that we need to be even faster, and we’re actively working on the next upgrades, but I think that going from syncing 0-blocks in the background to ~25_000 / day is enough of a performance improvement to significantly impact many user experiences.

[hanh]

@zancas

Based on this, I think that if Back Ground Sync runs for 10 minutes/day, then Zingo is syncing ~24 days per day of Back Ground Sync.

That shouldn’t be the case with background sync. In general, the amount of time it runs is hard to predict and therefore it cannot be extrapolated like that.

I don’t understand why you don’t simply measure it instead of estimating it.

You just need a phone and an old seed phrase.

[zancas]

I trust your numbers. I think it’s reasonable to back-of-the-envelope them, among other things it gives us an expectation to work against. But I take your point.

We’ll have more data soon, to compare against.

Actual deployed Back Ground sync runs overnight so we get a data point, per phone, per night.

[hanh]

Well, I’m talking about general engineering/research practices. It’s important to have reproducible experiments. There is no need to rely on trust since everything is publicly available.

For instance, I’d be happy to provide the seed phrase for a 2-month-old account and use the same hardware. I like to use an online test framework because it puts everyone in the same environment.

Once Zashi releases, it can be tested the same way.

PS: Ywallet has background sync too. I am not saying it is a bad thing.

[Dodger]

@zancas

• coordinated work with the Zcash Foundation to produce a pure Rust, backwards compatible alternative to zcash/lightwalletd

What do you mean by “coordinated work”?

@zancas

Per coordination with ZF, we haven’t heard anything from them yet.

I’m not aware of us receiving an email or similar requesting or proposing coordination with ZF. Did we miss something?