Electrum Fork for Zcash

3rd Party Applications
#1

Hi all,

i seen this github repository: https://github.com/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: https://github.com/ZcashFoundation/GrantProposals-2018Q2/issues/21

#2

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??

#3

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/

2 Likes
#4

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

#5

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.

1 Like
#7

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…)]

#8

Feel free to contact @moderators or use the Meta section of this forum for feedback to moderation decision.

#9

I think I found an answer here:

https://opensource.stackexchange.com/questions/9437/how-can-gpl-terms-apply-to-distribution-of-a-proprietary-plugin

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…

#10

The plugins would probably have to use a celery-based API, rather, to insure reliable delivery of all info from the electrum server…

#11

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…

#12

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.

#13

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…