We are applying for a ZCG grant to create a modern full node wallet with support for Unified Addresses, Unified Viewing Keys, payment URIs and a built-in address book to run alongside a zebra full node.
Question - Who sets the development plan at ZCG and how is it coordinated with the Foundation and ECC? So for example, who determines we need a Full Node Wallet (im not saying we dont, just want to understand how it works)?
a) does leadership determine, we Zcash need a XYZ project, please submit a proposal (or in this case a Full Node Wallet), or
b) do project teams reverse inquire about what they want to build and ZCG says yes or no
It’s hard to tell from the outside looking in what the process is.
Our stack can definitely be compiled into Windows binaries, but the wallet will always be dependent on Zebra’s capabilities.
Update: The ZF team pointed out at the Arborist call that you can have zebra on a Linux computer and the wallet could be on a Windows computer, talking to zebra over your LAN, with the requisite network security caveats. We will add support for this configuration on our roadmap.
I think there is a confusion of terms here. Classically, full node wallet referred specifically to an internal wallet residing inside of the full node of zcashd. Full node (external) wallet here means it is circumventing the use of a lightwalletd server and connecting directly to zebra. Zebra team is not building something resembling the zcashd full node internal wallet but the calls required for the Zenith full node external wallet are being, if not all already, built out so I don’t think there’s much more they could do anyways. The LCWG call would be a good place to talk about it and share ideas.
Nor do we plan to build a built-in wallet for Zebra.
I think it’s fair to say that there’s general consensus amongst the ECC and ZF engineers that the legacy “integrated-blockchain-node-plus-wallet” model has serious drawbacks. That’s one of the reasons we prioritised lightwalletd compatibility, and are currently working on blockchain scanning functionality, to allow third parties to build clients (including wallets) that can use a trusted Zebra node (or multiple Zebra nodes) as their sole interface to the Zcash network.
This is also my position; if the light wallet API is improved to support the full range of required functionality, then the only distinguishing feature of a “full node” wallet is that the wallet connects to a private light wallet server, either a local one (or one embedded directly into a zebra node, if such a thing were to be implemented to replace lightwalletd) or on a separate machine over a private and secure channel.
@pitmutt at the most recent meeting, the @ZcashGrants Committee voted to approve this proposal and has requested that you provide monthly updates via the forum in this thread.
The issue with zcash_script is entirely fixable problem, and the rest of Zebra is OS-independent, so this shouldn’t be discouragement to the wallet supporting Windows. Also note that a Windows user could run the Zebra node under WSL.
The LGPL isn’t two-way compatible with MIT: LGPL code can depend on MIT code, and MIT code can depend on LGPL code only as a library (in the sense defined by the LGPL), but LGPL code can’t be relicensed to MIT or freely mixed with code that remains MIT-licensed.
BP, ECC, ZF, and Major Grant recipients (during and leading to their award period) SHALL all accept the obligations in this section.
…
All substantial software whose development was funded by the Dev Fund SHOULD be released under an Open Source license (as defined by the Open Source Initiative [5]), preferably the MIT license.
(Zcash Community Grants is the successor of ZOMG which is the successor of MGRC, so this is a Major Grant for the purpose of ZIP 1014. If it weren’t then the constraint would have been on ZF to ensure that the contract with the grantee specified licensing that meets the requirement; as it is, the constraint is on the grant recipient directly, as are the other constraints in that section.)
LGPL is accepted as an Open Source license by OSI, but the wording does say “preferably the MIT license”. That would help reduce any risk of future license compatibility issues with other Zcash-related code. Was licensing discussed with ZCG during the grant consideration process, and is Zenith willing to relicense this code as MIT?
With my ECC R&D Engineering manager hat on, I think it’s highly desirable for all accepted ZCG and other Zcash grants to clearly specify what the licensing will be for any deliverables that are copyrightable works.
TL; DR: The zcash-haskell library and zenith will be released under the MIT License.
As the BOSL was removed from the Orchard crates, we updated the license to the LGPL-3, since at the time only our own ZGo app depended on the zcash-haskell library, before our application for Zenith.
Upon beginning the work for Zenith, we moved to the MIT license for both the library and the app and our upcoming releases will have those license updates.
We have made great progress on the first milestone for Zenith, focusing on the foundational elements of the wallet and text-based user interface.
This month we completed 15 pull requests for our new codebase covering the Zenith wallet and the zcash-haskell library. A preview of the new version of the interface connecting to Zebra on testnet can be seen in the video posted below. The layout of the TUI will change as we continue work but this can give you an idea of the kind of functionality we aim to provide.