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.
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.
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)
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.