ATTN: Anyone who works on Zcash

Required reading for @zooko et al:

Zcash could benefit from adding more elements of “fun”.

Currently, it has a serious and mission-driven attitude, larping as some purported savior of humanity.

ZECpages has been the closest thing to “fun”, I’ve seen, but nothing else has come close. This is what drew myself and others in.

tl;dr: more fun, less boring

4 Likes

Recurring payments was attempted a few years ago by @adityapk00 in ZecWallet but abandoned because of security reasons. Recurring Payments in ZecWallet (Testnet) - #3 by adityapk00?

Why not put a payment uri in a recurrent calendar appointment?

3 Likes

yeah wat if wallet synced in background every hour your phone is online?
dat way it wud take super little time and resources.
and any time u open wallet its already synced.

Phone apps don’t naturally run in the background. They get switched on and off. At best they can request to run a background service but more often than not, the OS will kill them to save battery.

See implementation in ywallet:

4 Likes

The issue here is that most places don’t accept ZEC. Chicken and egg problem.

You are probably within 1% of the population on Earth that has that many recurring payments.

I wonder if a ZGo integration into the Shopify App store would make sense: https://apps.shopify.com

cc @pitmutt :point_up:

You are comparing a centralized solution (PayPal) to a decentralized one (Crypto / Zcash).

Would you be able to make recurrent payments in Bitcoin? AFAIK, it’s not offered by any wallet.

1 Like

I am trying to hint that there is a good reason why people haven’t done it.
It can’t be done securely and reliably (one or the other but not both).

2 Likes

Shopify is a walled garden, unfortunately:

It also has a policy for refund functionality that would be difficult to comply with.

However, I am in touch with the devs working on Magpie Market, a federated alternative to Etsy and they are fully on board with having an integration with ZGo. I didn’t include this in our grant application because the project is in its early stages so there is no solid timeline for launch yet.

6 Likes

Do you have a list? I’d love to reach out to see how we could make it easier for them to get support with ZEC.

2 Likes

This derailed quickly from Pkr’s original topic. Recurring Payments are not fun.

Something that I’ve posited that could be fun and would also tickle the brains of our world-class software engineers.

Can we open source/ operate a private lottery in the Zcash protocol layer?

Overview:

  • on a randomized block interval
  • any shielded address that pays X ZEC into the shielded lottery address is eligible for X weighted tickets
  • at the lottery resolved block, only one among all of the shielded addresses that played receives all of the played ZEC
  • operate the lottery through a web/ mobile page not a new client application
  • bonus: if the community loves this idea, maybe the lottery code rake a tiny amount of each lottery pool into the ZSF

The obvious challenges would be auditability of both the code, per lottery participants/ ZEC lottery amounts, and the trailing outcomes (to assure that over time, randomness is true)

1 Like

Even if you audit everything, I don’t see how you can guarantee that whoever runs the lottery is really using that code.

2 Likes

I would suggest the following:

  • Create an official shielded address for the lottery
  • Publish the viewing key so that anyone can see the incoming funds and the payments
  • To play send some shielded funds from a transparent address or a shielded address with a reply memo
  • The account that runs the lottery pays every N blocks
  • The payment tx has a memo that includes the random number used to select the winner, a commitment to the next random number: H(random), and a settlement block height (current height + N).
  • winning number = PRF(random|settlement_block_hash). [0, 2^256] is partitioned based on the bet sizes and the winning bet is the one that includes the winning number. For example, if bets are [1 ZEC, 3 ZEC], the first bet gets [0, 2^254), and the second gets the rest.

It seems to me that this game is fair and verifiable.

4 Likes

No problem.

We’re working on a “tip jar” for this use case and having more info on what would be most useful would be helpful.

3 Likes