Creating an electrum-style "lite" client

[Droogans]

Extending on the ideas present in #239, but with an emphasis on handling BOINC integration end to end.

@jamescowens and @cyrossignol asked me to present a write up of issue at the most recent Fireside chat. Some of the high level ideas include:

1. Not attempting to replace the existing Gridcoin wallet, or implement this idea in it
2. Creating an experience for newcomers to BOINC to be as low friction as possible
   2a. Abstracting away teams, projects, CPIDs, beacons, accounts, and registration
   2b. Provide two options for "mining": GPU, and CPU, with any combination of the two allowed
   3c. These details exist as "lite-client CPIDs", managed by the hosted service. Includes u/p, emails, etc. all pointing to some foundation website, e.g., [email protected] which are possibly created in bulk, and in advance to limit "time to first crunch".
3. Lite-client hosts its own private keys, with all blockchain interactions occurring over RPC only (electrum-style). No blockchain is downloaded locally by this client.
   3a. Fund a single staking UTXO in the hosted gridcoin service for this new lite client, with side staking sending any rewards to their first address, set at ??% (let's just say 90% for the sake of simplicity).
   3b. These funds are made available to the hosted gridcoin service via investment from the foundation (90%/10%)
   3c. Alternatively, funds are provided by private parties, who then see a portion of the returns instead (90%/5%/5%)
4. Write it in electron or something else that can create a single web interface to desktop, and mobile apps
   4a. Install on a non-mobile device initially, somehow figure out CUDA for nvidia systems, etc. 🤷‍♂️
   4b. Link this "miner" on your phone via QR code, host as a lite wallet for GRC and a mining rig status checker
   4c. Ideally, fetch tasks, crunch, and submit as the client's only real "mining" responsibilities. Unsure of the feasibility here in order to avoid bundling a headless boinc installation...I imagine that restricting project selection here can help a little.
5. Taking an x% cut of all staking and mag-based earnings for any payouts sent via side-staking to lite client users, or private investors helping to fund the UTXOs used for this "hosted staking", as described in 3b. and 3c.
   5a. Include a GRC donation address for the continued funding of developer compensation, bounties, etc.

I don't know about the part where there's an eventual transition away from this lite-client. Ideally, the user would be shown a prompt requesting them to accept a change of their CPID's registration details once they'd installed a full node. The hosted service would update the CPID's reported email address, usernames/passwords, etc., on their BOINC projects after they hit ~4k total GRC, and are technically ready to start solo-crunching in the existing wallet interface.

I imagine that this would be important to figure out in advance, especially if there's interest in facilitating private investors to fund "hosted stakes". Something like that absolutely would require some kind of DeFI-like terms regarding the eventual return of the original investment after some notice period, such as Cosmo's ATOM. They include a 30-day notice required for withdrawal of staked funds to owners of assets. There may be some serious implications to the overall quality of the experience if it hinges on the presence of a large number of staking UTXOs in order to facilitate lite client "mining", especially if there's not enough there to actually support it.

Of course, this problem may not be as relevant as I expect, given that users with more funds are forced to share stake splits with other lite clients holding larger balances. Doubling or tripling up those users would be better overall if it meant freeing up 1:1 side staking (or even 2:1 ratios!) for brand new accounts, giving them that "gamification" boost that @jring-o said was an important factor in the project. I feel that this should strongly favor newcomers first, in order to maximize engagement, and boost adoption.

[cyrossignol]

@Droogans Thanks for taking the time to expand on your ideas. I actually started working on something similar to this a long time ago when I first discovered Gridcoin (before I got sucked into all the necessary changes for the Fern release). It seems as if you're describing a hosted service for payment processing (like what individuals and companies have built for other cryptocurrencies) that also provides for a simplified, integrated BOINC experience. A custom client interfaces with this service to trade some centralization in exchange for a greatly reduced learning curve for new participants, and users retain ownership of their private keys. The platform would provide a gentle transition to the full Gridcoin/BOINC ecosystems for users that want a deeper experience.

Your post describes some facets about the administration and economics of this service. These are important details to consider, and I'm sure others have great input to offer. I won't elaborate on my thoughts about these areas right now.

On the technical side, everything that you describe is possible. This is an ambitious project. Since you mention Electrum, it's worth noting that Gridcoin cannot yet build a faithful SPV implementation because the proof-of-stake consensus protocol makes it difficult to design secure light clients with our current technology. A light wallet would need to trust the centralized service to supply and relay transaction data. This may perturb some enthusiasts in this space, but perhaps a simplified on-ramp provides enough benefit for a particular class of users to justify that trade-off.

[whoisterencelee]

@cyrossignol insightful comments

The security of a simple web RPC interface (one without doing any cryptographic magic) has been on my mind as well, I try to start by thinking of a situation where I might own a million GRC and how I would feel if I have to trust my browser/app as I input the password to open the wallet. Some might feel that's secure, and others do not, a balance between convenience and risk of theft, perhaps fine tuned by a range of choices.

I would like an interface which make the users aware of their choices and the potential risks, even state what conveniences they would gain.

[jamescowens]

A few comments on the initial post and reacting to the responses above.

@cyrossignol is right. We cannot really do a true "light" wallet right now. The keys have to stay with the actual wallet that has the blockchain, so this "wallet" would have to be a remote parrot of a more centralized service. I don't think this is necessarily a bad thing. Many people don't seem to have a problem with centralized key storage, judging by the number of people using the wallet-bot, and also exchange wallets to store funds. I think if we make the back-end service secure, then folks would trust it. Note that service could very quickly become a target for hacking, and could be difficult to protect absolutely.

I think we have to cover two separate scenarios:

1. A newcomer to both GRC and BOINC that doesn't know much about either.
2. An established BOINCer that wants to get into GRC.

Note that the original post really covers 1 I think. If we are going to do a proxy BOINC client scenario, we have to think about the costs to support such an operation. That is not free. Currently (as people that currently crunch for GRC know) electricity and other costs of operation are greater than the GRC earned. Most enthusiasts are not doing this for the short term gain. I am not sure how a complete newbie is going to look at this. They certainly will not want to pay in more than earned to support the hardware.

[jring-o]

I could see an organization or some sort of entity filling the UX gaps the technology does not yet fill.

[Peppernrino]

Re: 2.

I have packaged the Gridcoin wallet for PortableApps.com. https://portableapps.com/node/63173

Along with BOINC now being portable https://portableapps.com/apps/utilities/boinc-portable my long dream of running everything from a USB stick etc is finally mostly realized... just need to figure out VirtualBox some more...

Anywho, everything being portable makes it so you can maybe put everything together in one big bundle... would save a lot of setup time. You'd basically just need to add projects and a CPID, and away you go. :)

[nathanielcwm]

I'm personally opposed to the use of Electron.

Would it be possible to port Bitcoin's pruning feature to Gridcoin?

[cyrossignol]

I'm personally opposed to the use of Electron.

@nathanielcwm Electrum is a "light" wallet implementation for Bitcoin. It uses Qt, not Electron (the UI framework).

Would it be possible to port Bitcoin's pruning feature to Gridcoin?

Not really. Pruning is relatively simple for proof-of-work coins. Gridcoin's proof-of-stake protocol needs a different pruning strategy. It's doable, but less effective, and there are no upstream projects to adopt this feature from yet—we'll need to write it ourselves. Also, pruning only reduces the disk storage burden. A node must still download and validate every block in the chain. This is a big obstacle for many mobile devices which can benefit the most from using light clients.

[nathanielcwm]

@nathanielcwm Electrum is a "light" wallet implementation for Bitcoin. It uses Qt, not Electron (the UI framework).

I was referring to part 4 where @Droogans suggested writing the light wallet in electron.

I don't have any qualms about electrum

[springfielddatarecovery]

Really love this idea. It seems like there are really two main ideas you're proposing here:

1. A single cross-platform installer to handle BOINC/Gridcoin wallet that abstracts away all the current headaches associated with getting started. I think this is a critical piece of infrastructure for wider adoption and would contribute towards a dev fund for this. Basically "run this exe and you're mining and earning rewards"
2. A cross-platform light client that doesn't require the full blockchain and is able to do some staking. I'm not sure that staking needs to be the default setup for this and it seems like doing so (through third parties or sidestaking) complicates things, but it would be a handy feature. Regardless, a light client is also kind of a must when we compare Gridcoin to other coins and enables Gridcoin to be used on mobile devices.

I think from an infrastructure level, idea number one is probably not suited for some ultra-cross-platform solution like Electrum. Each system is going to be different and I think you'd end up working against Electrum more than with it, especially on the BOINC side.

[Droogans]

I've come back to this idea a few times, and it's been a while, so seeing feedback here means a lot. Hopefully I can try and clarify a few details to be more up to date to how I've considered things now that I've read these great comments. Thanks everyone.

The more I think about it, and the more I realize that people can easily run a fully synced, wallet-enabled, INVESTOR node, it's that last part that gets everyone stuck. That may be a reliable way to assume that there's trustworthy block data available to the user.

[Peppernrino]

could there maybe be a call to a remote server containing some "verified" version of the blockchain? i know, i know, decentralization... but a light wallet comes with its own caveats in the first place, so... let's just stop that conversation before it starts. lol

[nathanielcwm]

could there maybe be a call to a remote server containing some "verified" version of the blockchain? i know, i know, decentralization... but a light wallet comes with its own caveats in the first place, so... let's just stop that conversation before it starts. lol

wasn't that how coinomi worked?

[Peppernrino]

i think that might be how coinomi works, yeah. and maybe mycrypto?