A good deal of functionality beyond the initial grant is already in place. We have key derivation, a few BIPs and ZIPs implemented, and .NET APIs that expose some of the functionality required for .NET to act as a lightwallet client.
In the next month, I hope to implement and stabilize most functionality except for transaction download and creation – the functionality that actually requires interacting with the blockchain. I have prototypes of a very limited set of lightwallet sync functionality, but there’s lots more work to do. I’m consuming ZingoLib (from the Zingo team, also funded by a Community Grant) for some of this functionality, and that team is working through some bugs and features that will be important for this project to consume, so scheduling this work for more than a month out should help our requirements and their features align.
In the next month, as expected I’ll be working on sync functionality (download and sending transactions) and balances. I hope to provide APIs by which a wallet app can convey very user-friendly concept balances (i.e. not the same ones I tend to see in wallets today). Here’s an example:
True auto-shielding functionality is also on the backlog, and I hope to get it done in the next 30 days as part of the sync work.
Finally, and this is something of a stretch goal, I hope to include shielded pool balancing functionality so that the wallet app (or user) can decide what proportion of their funds to keep in sapling vs. orchard. When each shielded pool carries a balance, payments are less likely to have to cross the turnstile, revealing the amount (or at least a clue about the amount) in a transaction.
