Announcing Zingo!

[teor]

I think this is a great idea, I think financial support for developers is important.

(I work for the Zcash Foundation as a developer, so I have an interest here. But sustainable funding is a well-known problem in open-source development.)

I have a few questions about the implementation details:

@zancas

The Privacy Enhancement Fee:

• If you transact with zingo, you will be offered the option to send 3 zats to Enhance Your Privacy:
  • 1 to The Zcash Foundation
  • 1 to the Electric Coin Company
  • 1 to Zingolabs.

This explicit fee will ensure that your service is viable and adaptive in direct proportion to how much you use it. If you opt to not pay the Privacy Enhancement Fee, it is still likely that others will, making zingo the application you should prefer for your consensual (all) transactions.

1. How do you send these 3 Zats in a privacy-preserving way?

Here are some ways I could discover and track shielded Zingo transactions:

• Each transaction has 5 shielded outputs (or 2 shielded, and 3 times 1 transparent Zat)
• The public value balance fields of shielded transactions end in …00003 Zat, if the original number of Zat was a multiple of 10

It would be unfortunate if the “privacy enhancement fee” actually ended up reducing privacy in practice. Can I see the privacy analysis for this design?

2. Have you asked ECC and ZF if they want to receive hundreds or thousands of 1 Zat contributions?

There is a well-known attack called the dust attack, which sends large numbers of very small amounts of cryptocurrency.

Sending extra Zats for each transaction isn’t quite the same, but it could have an impact on the ECC, ZF, and ZingoLabs wallets, if Zingo becomes popular.

ECC and ZF already receive thousands of transparent inputs per day from Funding Streams. But they might not be prepared for thousands of shielded inputs. And it could cost them extra staff time to roll up those small amounts.

3. Does sending those 3 Zat cost the Zcash network more than the value sent?

Creating and spending each shielded transfer uses some CPU. The create and spend also take CPU to verify, and disk space to store, on every active node. (There are about 200 public nodes right now.)

It seems like the extra CPU would cost more than 1 Zat.

But I think there’s a solution that makes all these problems better!

You could send an amount that’s significantly greater than the staff, CPU, and disk cost. Maybe that means increasing the contribution, or storing the contribution amounts locally, until they get large enough.