Hi all,
i seen this github repository: GitHub - zcash-community/electrum-zec
I have no idea where we are with development.
I would like to understand what the difficulties are and what it takes to carry it forward
EDIT: grant submission: Fork electrum to zcash and enable shielded transactions · Issue #21 · ZcashFoundation/GrantProposals-2018Q2 · GitHub
Any status report on this?
Given ZEC’s recent commitment to an eventual proof of stake, my interest in ZEC has gone WAY up. The advantage of having an electrum wallet would be:
support for timelock
handling for dust
a platform for PLUGINS! hardware wallets, transaction services, etc.
Is this the right place to comment on this? Or should it be at the git above? Or on the zcash development channel on discord??
Hey @steve.b welcome to the forum, this is quite an old project that was awarded a grant in 2018 completed back in 2019:
But doesn’t seem to have been kept up to date. If it’s something you would be interested/able to work on and get working with upcoming NU5 Halo (this month) I’m sure the Zcash Community Grants Committee would consider supporting updating it:
https://zcashcommunitygrants.org/
Thanks; I would be interested. It’s a question as to whether I can turn it around quick enough.
I think a good place to start is for me to talk to the developer who ported the first version and ask:
why it’s not been kept up to date (a lot of updates coming from electrum? zcash? both??)
what was implemented under it (handling for dust? plugins? timelock?) and any gaps in it
I wouldn’t worry about trying to turn it around before NU5, Halo introduces new address types (UAs) and many other improvements so the code will probably need significant revision to be compatible.
That said, if it’s brought up to date, it could be a good foundation for others for work/fork from and support Zcash in thier wallets.
One thing I see as generating a lot of interest would be supporting a plugin architecture running on the electrum server. To generate maximal interest, I would like plugins to be any license a person or organization chooses; be it MIT, GPL, or proprietary.
Was just reading the discussions on BOSL (this being the original one: BOSL or MIT - Orchard - #29 by fireice_uk) If the electrum port of the server for ZEC’s stake chain is governed by BOSL, would that requirement also have to extend to plugins? Logic tells me no, but…
[I understand the reason for the BOSL (though I might have suggested a grace period of 2 years instead of one…)]
Feel free to contact @moderators or use the Meta section of this forum for feedback to moderation decision.
I think I found an answer here:
The plugins would have to be run in a separate server process, as a separate suite of REST, and/or websocket or graphql endpoints. While this would introduce additional processor memory space overhead when run on the same server, or network latency when run as a cluster, it could allow for greater resources to be marshalled on the electrum server when the plugins are run on their own dedicated server…
The plugins would probably have to use a celery-based API, rather, to insure reliable delivery of all info from the electrum server…
which would require the addition of a message broker.
I can now see the argument that BOSL should convert to an MIT license at the end of one year! This introduces more moving parts…
In general this is a very grey area (similar to the “system library exception”) of GPL. I would dig deeper than the first SE question.
FYI; I posted for the grant here: ElectrumZ
If anyone has any constructive criticism of what I’m shooting for, I welcome discussion of it on this thread…
Electrum protocol (stratum) requires access to address history and therefore only works with public coins.
It won’t be possible to implement the API needed for Zcash.
For ex:
https://electrum.readthedocs.io/en/latest/protocol.html#blockchain-address-get-history
Edit: Just to be clear, I am referring to shielded addresses. ElectrumZ used to support Zcash but transparent addresses only. Since this grant specifically refers to NU5+HALO, it seems to target Orchard shielded addresses.
Yes, I am aware of that. I have a proposal to extend the electrum command set to support passage of the keys necessary to interpret addresses; in all other respects, the command set is downlevel compatible with btc. It could be run against the bitcoin blockchain to support operation with btc; but using the extension arguments and the server has a toggle to indicate it’s running against the zcash blockchain, it acts the same way.
That’s why I am leveraging off the Electrum PERSONAL Server codebase (as opposed to, say, ElectrumX…); you wouldn’t want to be sending keys up to a shared server. Also: Electrum Personal Server supports pruning; that would be essential for a private node. And it would permit the interoperation with a node being run in pruned mode as the zcash blockchain grows (what can I say? I’m optimistic…)
The strategy of having an electrum server that supports both btc and zec:
It assists with regression testing. If it doesn’t work for btc, you know the same codebase can’t work for zec.
It provides an easier on-ramp to zcash for bitcoin developers who are familiar with electrum
Using existing electrum wallet code, it’s easier to derive a “wallet plugin” for zcash (that’s a follow-on step once the server is tested out…) The electrum wallet has ~100,000 lines of code -that’s a wheel I would rather not completely reinvent.
Incidentally: I have already modified Electrum Personal Server to support multiple connections (something the standard Personal Server does not do yet…)
A nice thing about a zcash grant (for the zcash grants committee) is they don’t have to pay until you deliver a working product…
Please bear in mind that users would compromise their privacy if they send their viewing keys to the server. Also from a technical perspective, scanning server side for every user would induce a hefty load.
Good luck with your grant
It’s a personal server; private, down the road run alongside a wallet on the same machine instance. It could point to a shared node living elsewhere, or a dedicated node running on the same device. But the personal server does not send keys to the node; a wallet sends keys to the dedicated personal server.
Think of it as a microservice…
PS Wallets should be run on dedicated devices; if I were to do an installer (i.e., I get the grant…), I would require an acknowledgement to be made that that is understood…
Will it be necessary to run a full node along side?
No; the Personal server can talk to a remote node via SSL (you could configure stunnel…)
But if you like autonomy, full nodes are nice. And as I pointed out: you can always run one alongside pruned, thanks to Personal Server supporting that.
If the node is going to support wallet calls -then yeah; you would need that the node run alongside the wallet. But no big since you can run it pruned. [Personal Server leverages off a node’s wallet; a wallet must be enabled on the node…]
My installer plans to manage setup of three components:
a zcash node
an Electrum Personal Server that interoperates with that node
a “plugin server” that can host microservices that can access the Personal Server; this could host a wallet plugin (a subsequent proposal…); a SQL blockchain ingester; or whatever you like…
The interesting thing about the plugin server is that it will honor execution of each microservice plugin by means of forked sockets (each plugin running in its own process…) This permits a GPL3, MIT, or other licensed plugin to access the ElectrumZ server while still honoring the constraints of a GPL3 license (which BOSL licenses convert to…) So people get motivated to write plugins for the ElectrumZ server (which adds utility to the zcash ecosystem and fosters its growth…)
If it is not your own node, you would lose privacy by handling them your keys wouldn’t you?
If the installer sees you want to run a wallet, it does set up a dedicated node of yours on the same machine for you (so in that case, you get your own node, run pruned if you like -it will ask…)
[FYI: elaborated on answerS above…]