BUIP133: Electron Cash Improvements

[imaginary_username]

BUIP133: Electron Cash Ecosystem Improvements

Submitted by: Jonald Fyookball
Date: 2019/10/3
edit Sponsored by: imaginary_username and Andrew Clifford 3 Oct 2019
revised project order 9 Nov 2019

Motivation:

The Electron Cash wallet is a focal point for the Bitcoin Cash application layer. There are a number of projects that can add value and strengthen the software and ecosystem, but currently most efforts are on a volunteer basis. The Electron Cash group seeks $51,200 in order to accomplish the following projects:


Goals:

Project #1: “Faster SPV Server”

Get Electron Cash “talking” to electrs and/or bchd rather than just ElectrumX

Synopsis: ElectrumX is the server software that Electron Cash uses in order to interact with the blockchain. It suffers from performance and feature limitations, which either need to be fixed, or Electron Cash should use other server software. It would be a good time investment to get Electron Cash “talking” to other SPV services such as bchd or BU’s electrs.

Obstacles / Challenges / Goals: There is a very fast SPV server implementation from BU called electrs but it still needs some feature additions. Calin Culianu has offered to work with the BU team in ironing out any final touches to get electrs to be at least as good or better than ElectrumX in terms of featureset. Electrs, being entirely native code, runs much faster than ElectrumX and is multi-core. It needs a few niceties such as SSL support and “Server Federation” (creating a mini p2p network of servers). This software is built-in to BU optionally and thus has the potential to be installed on many full nodes on the network. Additionally, bchd gRPC shows promise (is native, is fast, is deployed in many places) but needs a few minor feature additions as well. Working with these teams, Electron Cash could get them to the 100% feature level needed -- development and coordination time is needed.

Resources Needed: Development time from one or more of the Electron Cash and/or collaboration with Dagurval or another BU developer and/or bchd developers such as Chris Pacia.

Estimated Cost: 200+ hours developer time.

Project #2: “CashShuffle iOS”

CashShuffle is loved by all. It needs to come to Electron Cash’s iOS implementation.
Synopsis: The Bitcoin Cash ecosystem has by and large had a positive reaction to Electron Cash’s CashShuffle. Many users are asking for an iOS port of the subsystem to work in the existing Electron Cash for iOS wallet app.

Resources Needed: Development time from Calin Culianu.
Estimated Cost: 100 hours development time

Project #3: “Android Phase 4”

The Android version of Electron Cash has one more phase to complete its core feature set. Finishing this brings the basic wallet to completion and makes it ready for enhancements like SLP and CashShuffle/Fusion.

Synopsis: Here are the specific features being added:

• Wallets:
  • Rename (including closed wallets)
  • Export (including closed wallets)
  • Delete (add ability to delete closed wallets)
• Send:
  • Export and import unbroadcast transactions
• Addresses
  • Freeze
  • Sign / verify
  • Private key
  • Encrypt / decrypt
• Coins screen
  
  
• Settings:
  • Transactions:
  • Use multiple change addresses
• Show notification if payment received when app in background

Resources Needed: Development time from Malcolm Smith or other android developer
Estimated Cost: 100 hours development time

Project #4: “EC/SLP Merge”

SLP (Token) Integration into the Electron Cash main codebase and discontinuing development on the EC-SLP Branch

Synopsis: The Electron Cash main codebase does not support spending/creating SLP tokens. It needs this functionality, and the Electron Cash SLP codebase needs to be discontinued, in the interests of efficiency and simplicity for both users and developers.

Obstacles / Challenges: Careful review of the Electron Cash SLP pieces that will be brought into Electron Cash must be done. Electron Cash regular is a somewhat more complex wallet than EC-SLP, because of CashShuffle, and care must be taken to not impact its performance needs. Code review and rewriting of existing pieces from EC-SLP is anticipated, as well as some reworking of the UI.

Resources Needed: Development time from one or more of the Electron Cash and/or SLP developers such as Calin Culianu, James Cramer, Axel Gembe, Mark Lundeberg or others.

Estimated Cost: 250-350 hours developer time.

Project #5: “Skin System”

A skinning system based on the existing ui’s QT framework. This allows the wallet to have various designs and color themes.
Synopsis: The idea to create a skin system is not for novelty purposes. This actually is our most viable idea for the Electron Cash developers create a business model that will sustain development in the future. Everybody loves skins and we will monetize it.

Resources Needed: Development time from Axel Gembe, Calin Culianu or other QT specialist python developers.

Estimated Cost: 400 hours development time

(cont'd)

 

[imaginary_username]

Project #6: “SLP iOS”
Simple Ledger Protocol has taken the BCH world by storm. It needs to come to Electron Cash’s iOS implementation.

Synopsis: Many users are asking for an iOS port of the subsystem to work in the existing Electron Cash for iOS wallet app.

Resources Needed: Development time from Calin Culianu.

Estimated Cost: 200 hours development time

Project #7: “Private Reusable Addresses”
Make Electron Cash implement imaginary_username’s “reusable address” specification.

Synopsis: Reusable addresses allow for an identifier such as a CashAccount to be used to derive non-repeating addresses for discrete repeated payments to the same person, using a new address each time, so that one does not have to choose between privacy and usability - one can have good privacy while only giving out an address just once. Enables convenient, no-compromise handles for mass adoption.

Resources Needed: Development time from one or more of the Electron Cash developers such as Calin Culianu, in conjunction with server-side work such as bchd modifications from Josh Ellithorpe, as well as specification/protocol work from imaginary_username.

Estimated Cost: 100-300 hours development time across multiple developers..

Project #8: “Keyserver”
Allow Electron Cash to integrate with Cashweb’s Keyserver software.

Synopsis: Harry Barber and Shammah Chancellor have written “keyserver” software for storing blockchain-related data in a separate peer-to-peer network that is tightly integrated with the BCH blockchain.

Goals / Outcomes: This key piece of infrastructure allows wallets to come alive. You can register data or share data with your friends all from within your wallet. Send contact vCards or lookup your friend’s aliases or addresses, send them instant messages, or store authenticated data for sharing with others -- all signed and associated with your bitcoin address.

Resources Needed: Harry and Shammah are already developing the GUI pieces needed for Electron Cash to integrate with this service, but more development time from one or more of the Electron Cash developers such as Calin Culianu would be helpful.

Estimated Cost: 50 hours development time.

Project #9: “More Robust and Private backend”
Make Electron Cash more robust against server withholding, leak less privacy to its SPV servers.

Synopsis:

A longstanding drawback of Electron Cash’s model of fetching all transactions from a single server is that the server can withhold transactions from the client, resulting in complications for receiving payment.

On top of that, Electron Cash publishes its entire list of addresses to a single server to which it connects, potentially leaking privacy to the server which can trivially find address/spending linkages. Right now the only real mitigation is via running your own server, Tor is a slight improvement.

Both of these can be fixed with a more intelligent strategy which it can distribute load to add redundancy across servers, while not revealing “too much” to any one server. Electron-cash then becomes more reliable and robust for receiving payments.

Resources Needed: Development time from one or more of the Electron Cash developers such as Calin Culianu.

Estimated Cost: 100-200 hours developer time.

Project #10 “Continuing Support and Protocol scalability”
Electron Cash needs constant upkeep and bug fixing. New libraries and hardware wallets appear periodically and the code needs maintenance frequently. It is a mostly volunteer effort but some funding would make things much better.
Apply unfinished protocol tweaks to enable massive scale.

Synopsis:

The Electron-Cash/Electrumx protocol contains a few weak points that hinders its scalability, particularly when it comes to massive wallets made more common by Cashshuffle, as well as big single-address wallets common for commercial and donation uses. We have identified a few protocol weak points such as transmission pagination and status update algorithm that could use tweaking to prepare for better scaling, which is in line with the BCH roadmap.

Resources Needed: Protocol discussion from Electron-cash developers, as well as review from wider BCH development community

Estimated Cost: 100 hours of developer time

Cost Summary for all Projects:

Total cost: 1600-2000 hours of developer time.
Discount rate: $32/hr @ 1600 hours = $51,200

Jonald_fyookball and imaginary_username can report back on progress as the goals are being fulfilled, members can also track them at https://github.com/Electron-Cash/Electron-Cash. Even a part of the goals should bring tremendous value to the BCH ecosystem, while the funding brings stability and predictability to Electron-cash development, which is currently largely staffed by volunteers.

 

[solex]

@imaginary_username
As discussed with Jonald, I will co-sponsor this and subject to revision by membership feedback will include it in the next vote.

 

[theZerg]

I think that BU funding should mainly remain within BU initiatives instead of funding peer projects. Electron Cash and BU are effectively in similar roles -- we provide infrastructure.

Companies that are deriving profits from Bitcoin Cash should take the initiative to fund this infrastructure. We should look at fulfilling needs that these companies have.

Additionally, as an aside/feedback to the proposers: if I imagine myself in such a company, I don't see a story here that moves adoption to the next level. I don't even see an implausible one -- it seems to be not a concern.

 

[Peter R]

I think these are all good initiatives, but I'm worried that most are too far from BU's mandate. I think "Project #6: Faster SPV Server" is the only one that's an obvious fit. The backend infrastructure for scaling SPV is important, and would help address some of the limitation Jameson Lopp pointed out in this CoinDesk article from 2017: https://www.coindesk.com/spv-support-billion-bitcoin-users-sizing-scaling-claim

I would vote "yes" to funding this (and at potentially a higher level than what you've indicated--be realistic with your budgets). This would give you some funding to keep going, and only one deliverable. If you can get other features done at the same time, then all the power to you. Another BUIP can be raised in the future to do more, and will be likely to succeed if the first project bears fruit.

 

[theZerg]

I think what @Peter R is saying is that if you isolate Project#6 and pro-rate its portion of the 51k based on its reported times vs. the other work, we can guess at a funding amount for just #6. And that he'd be OK with funding this for approximately that number. You should come back to us with a number because we understand that you can't necessarily get #6 done in isolation for this exact pro-rated amount. I don't think he's saying that 51k or more should be put onto just #6. Please @Peter R correct me here if I'm wrong.

I could get behind a new proposal like that as well. Jonald, if you are interested in that why not submit a new BUIP proposal, maybe expanding on exactly what needs to be done, and withdraw this one? If you want to do this, operationally, I'd suggest that you make a new post with the new BUIP, and leave this conversation around for historical purposes. We will edit the title here to indicate this post has been superseded by a new proposal to avoid confusion.

 

[imaginary_username]

Switching positions per suggestions in thread and with permission from Jonald:

BUIP0XX: Electron Cash Ecosystem Improvements
Date: 25 September, 2019
Proposers: Jonald Fyookball (jonaldfyookball@outlook.com)
Sponsored by Andrew Clifford
Motivation:

The Electron Cash wallet is a focal point for the Bitcoin Cash application layer. There are a number of projects that can add value and strengthen the software and ecosystem, but currently most efforts are on a volunteer basis. The Electron Cash group seeks $51,200 in order to accomplish the following projects:

Project #1: “Faster SPV Server”
Get Electron Cash “talking” to electrs and/or bchd rather than just ElectrumX

Synopsis: ElectrumX is the server software that Electron Cash uses in order to interact with the blockchain. It suffers from performance and feature limitations, which either need to be fixed, or Electron Cash should use other server software. It would be a good time investment to get Electron Cash “talking” to other SPV services such as bchd or BU’s electrs.


Obstacles / Challenges / Goals: There is a very fast SPV server implementation from BU called electrs but it still needs some feature additions. Calin Culianu has offered to work with the BU team in ironing out any final touches to get electrs to be at least as good or better than ElectrumX in terms of featureset. Electrs, being entirely native code, runs much faster than ElectrumX and is multi-core. It needs a few niceties such as SSL support and “Server Federation” (creating a mini p2p network of servers). This software is built-in to BU optionally and thus has the potential to be installed on many full nodes on the network. Additionally, bchd gRPC shows promise (is native, is fast, is deployed in many places) but needs a few minor feature additions as well. Working with these teams, Electron Cash could get them to the 100% feature level needed -- development and coordination time is needed.

Resources Needed: Development time from one or more of the Electron Cash and/or collaboration with Dagurval or another BU developer and/or bchd developers such as Chris Pacia.

Estimated Cost: 200+ hours developer time.

Project #2: “CashShuffle iOS”
CashShuffle is loved by all. It needs to come to Electron Cash’s iOS implementation.
Synopsis: The Bitcoin Cash ecosystem has by and large had a positive reaction to Electron Cash’s CashShuffle. Many users are asking for an iOS port of the subsystem to work in the existing Electron Cash for iOS wallet app.

Resources Needed: Development time from Calin Culianu.

Estimated Cost: 100 hours development time

Project #3: “Android Phase 4”
The Android version of Electron Cash has one more phase to complete its core feature set. Finishing this brings the basic wallet to completion and makes it ready for enhancements like SLP and CashShuffle/Fusion.

Synopsis: Here are the specific features being added:

• Wallets:
  
  
  • Rename (including closed wallets)
  • Export (including closed wallets)
  • Delete (add ability to delete closed wallets)
    
• Send:
  
  
  • Export and import unbroadcast transactions
    
• Addresses
  
  
  • Freeze
  • Sign / verify
  • Private key
  • Encrypt / decrypt
    
• Coins screen
  
  
• Settings:
  • Transactions:
    • Use multiple change addresses
      
• Show notification if payment received when app in background
  

Resources Needed: Development time from Malcolm Smith or other android developer

Estimated Cost: 100 hours development time

Project #4: “EC/SLP Merge”
SLP (Token) Integration into the Electron Cash main codebase and discontinuing development on the EC-SLP Branch

Synopsis: The Electron Cash main codebase does not support spending/creating SLP tokens. It needs this functionality, and the Electron Cash SLP codebase needs to be discontinued, in the interests of efficiency and simplicity for both users and developers.

Obstacles / Challenges: Careful review of the Electron Cash SLP pieces that will be brought into Electron Cash must be done. Electron Cash regular is a somewhat more complex wallet than EC-SLP, because of CashShuffle, and care must be taken to not impact its performance needs. Code review and rewriting of existing pieces from EC-SLP is anticipated, as well as some reworking of the UI.

Resources Needed: Development time from one or more of the Electron Cash and/or SLP developers such as Calin Culianu, James Cramer, Axel Gembe, Mark Lundeberg or others.

Estimated Cost: 250-350 hours developer time.


Project #5: “Skin System”

A skinning system based on the existing ui’s QT framework. This allows the wallet to have various designs and color themes.
Synopsis: The idea to create a skin system is not for novelty purposes. This actually is our most viable idea for the Electron Cash developers create a business model that will sustain development in the future. Everybody loves skins and we will monetize it.


Resources Needed: Development time from Axel Gembe, Calin Culianu or other QT specialist python developers.


Estimated Cost: 400 hours development time

 

[imaginary_username]

Project #6: “SLP iOS”
Simple Ledger Protocol has taken the BCH world by storm. It needs to come to Electron Cash’s iOS implementation.

Synopsis: Many users are asking for an iOS port of the subsystem to work in the existing Electron Cash for iOS wallet app.

Resources Needed: Development time from Calin Culianu.

Estimated Cost: 200 hours development time

Project #7: “Private Reusable Addresses”
Make Electron Cash implement imaginary_username’s “reusable address” specification.

Synopsis: Reusable addresses allow for an identifier such as a CashAccount to be used to derive non-repeating addresses for discrete repeated payments to the same person, using a new address each time, so that one does not have to choose between privacy and usability - one can have good privacy while only giving out an address just once. Enables convenient, no-compromise handles for mass adoption.

Resources Needed: Development time from one or more of the Electron Cash developers such as Calin Culianu, in conjunction with server-side work such as bchd modifications from Josh Ellithorpe, as well as specification/protocol work from imaginary_username.

Estimated Cost: 100-300 hours development time across multiple developers..

Project #8: “Keyserver”
Allow Electron Cash to integrate with Cashweb’s Keyserver software.

Synopsis: Harry Barber and Shammah Chancellor have written “keyserver” software for storing blockchain-related data in a separate peer-to-peer network that is tightly integrated with the BCH blockchain.

Goals / Outcomes: This key piece of infrastructure allows wallets to come alive. You can register data or share data with your friends all from within your wallet. Send contact vCards or lookup your friend’s aliases or addresses, send them instant messages, or store authenticated data for sharing with others -- all signed and associated with your bitcoin address.

Resources Needed: Harry and Shammah are already developing the GUI pieces needed for Electron Cash to integrate with this service, but more development time from one or more of the Electron Cash developers such as Calin Culianu would be helpful.

Estimated Cost: 50 hours development time.

Project #9: “More Robust and Private backend”
Make Electron Cash more robust against server withholding, leak less privacy to its SPV servers.

Synopsis:

A longstanding drawback of Electron Cash’s model of fetching all transactions from a single server is that the server can withhold transactions from the client, resulting in complications for receiving payment.

On top of that, Electron Cash publishes its entire list of addresses to a single server to which it connects, potentially leaking privacy to the server which can trivially find address/spending linkages. Right now the only real mitigation is via running your own server, Tor is a slight improvement.

Both of these can be fixed with a more intelligent strategy which it can distribute load to add redundancy across servers, while not revealing “too much” to any one server. Electron-cash then becomes more reliable and robust for receiving payments.

Resources Needed: Development time from one or more of the Electron Cash developers such as Calin Culianu.

Estimated Cost: 100-200 hours developer time.

Project #10 “Continuing Support and Protocol scalability”
Electron Cash needs constant upkeep and bug fixing. New libraries and hardware wallets appear periodically and the code needs maintenance frequently. It is a mostly volunteer effort but some funding would make things much better.
Apply unfinished protocol tweaks to enable massive scale.

Synopsis:

The Electron-Cash/Electrumx protocol contains a few weak points that hinders its scalability, particularly when it comes to massive wallets made more common by Cashshuffle, as well as big single-address wallets common for commercial and donation uses. We have identified a few protocol weak points such as transmission pagination and status update algorithm that could use tweaking to prepare for better scaling, which is in line with the BCH roadmap.

Resources Needed: Protocol discussion from Electron-cash developers, as well as review from wider BCH development community

Estimated Cost: 100 hours of developer time

Cost Summary for all Projects:

Total cost: 1600-2000 hours of developer time.
Discount rate: $32/hr @ 1600 hours = $51,200

 

[theZerg]

I think that the crux of my (and others) posts above was to ask BU for funding for just the "Faster SPV Server" portion, not to meaninglessly reorder the items in the list.

Meanwhile, Dagur has talked to Calin and determined that the intention in the "Faster SPV Server" portion is to implement something from scratch in Rust. However, BU already has a working Rust-based implementation forked off of electrs called "Electrscash". I was informed that Calin was made aware of this, yet still wants to re-implement. [If there is anything incorrect about this account, please offer your version as part of the discussion here]

If there are reasons why a from-scratch implementation could be made to significantly outperform Electrscash (which can evolve to add many new ideas), then the BUIP should cover those reasons in detail.

It is not a good use of our money to work on redundant implementations, and as originally mentioned, I do not see it as BU's role to generally support development across the ecosystem. Instead, it is industry's (that is, the revenue generators) role to do so for BU and other development groups, for those initiatives that interest them. For these 2 reasons, I intend to vote "no" for this proposal.

 

[solex]

It looks like a lot more discussion and reworking of this BUIP needs to occur before it can be brought forward for vote, so I will leave it in draft for the present time. I agree that the potential for a lot of duplication of work is a major concern.

 

[imaginary_username]

@theZerg there were discussion regarding whether there are unresolvable bottlenecks in Electrs that is better dealt with in a from-scratch implementation; I am not involved in the effort, but last time I checked Calin, Harry and @dagurval were in conference regarding the best path forward, it was a while ago. I was under the impression that they came to some sort of consensus, but it'll be good to get information from people directly involved.

 

[freetrader]

@imaginary_username So many of these things are stuff I would have hoped the "General" funds raised by FVNI through bitcoin.com could start covering.

I'll take this BUIP as a sign that that's not happening soon (enough).

I'll be honest and say that my expectations for BU membership to fund these under its remit aren't all too great, but it's great that you have documented these needs clearly and put numbers to them.

Hopefully, in case this doesn't reach a vote this time round, you (the plural persons behind these needs) would consider opening these up as community fundraisers of their own which the bigger (than BU) community could fund. It would be terrible if some of these important tasks just sit because they don't have insufficient funding.

 

[dagurval]

@theZerg [..] I am not involved in the effort, but last time I checked Calin, Harry and @dagurval were in conference regarding the best path forward, it was a while ago. I was under the impression that they came to some sort of consensus, but it'll be good to get information from people directly involved.

Last I heard Harry was making good progress on his from-scratch implementation, which also including re-designing the protocol itself. He's going to explore that further and I'm not involved.

 

[imaginary_username]

@solex Jonald requested an addendum to be appended below the BUIP text:

Addendum: There is no guarantee if and when all the above projects will be completed. The key points here are that A) the above cost estimate is substantially discounted, and B) the developers and other contributors in the Electron Cash community have a track record of adding value to the ecosystem and completing projects.

 

[imaginary_username]

(Thanks Dagur for clearing it up)

With this addendum, both Jonald and I will like to see the BUIP go ahead for this voting session - I'm not sure specifically what kind of modifications can be made to make it more appealing. Whichever server implementation we end up with, work on protocol and hence client side efforts will be needed - the membership should get a say on how much that is valued in regards to the organization's mission.

 

[solex]

@solex
With this addendum, both Jonald and I will like to see the BUIP go ahead for this voting session -

@imaginary_username
Your revised text is noted for updating the BUIP, however, it looks like there is confusion, evidenced from this "There is no guarantee if and when all the above projects will be completed."
The BU executive has a responsibility to ensure that funds are expended properly and this includes development being evidenced. We will need to add a line to clarify how it works: "When each project meets completion, with all code merged and present and functional in the latest main branch Electron general release to the public, then funding for that project is released to the Electron developers."