- Problem 1
The client takes way too much too sincronize. Not only the first time, but also for people who dont keep the wallets open too often.
Proposed solution :
Optional rsync nodes that sync automatically when you are too many blocks behind . As an example, gentoo's Portage system is an excelent example of a system like this in action .
The design is very straightforward.
- First, we need a master server or servers to be mirrored . Preferably dev-operated . They will mark the consensus around servers and also provide the list of nodes to the wallets.
- Second, anyone should, at any time , be able to request to volunteer in the mirror-list. To do so you will need a static ip, or at least a dynamic DNS service such as no-ip, a good enough uptime, and a minimum of computing and network capabilities. Basically, most people who should be interested on this are people with VPS or even dedicated servers who keep a wallet staking, or boinc running when idle, or both... Every hour, in a FIFO order, a server should synchronize with the master.
- Third, when users have fallen too much behind, or are doing their first sync, unless they have this specific option disabled, they must start synchronizing selecting a random server. Users should also be able to force it to make the way out of a network fork much easier.
To afford this service, nodes should either receive an user donation budget to be distributed among them, or receive part of the network fees.
The possibilities of taking over the network are minimal since it would require taking over a majority of nodes and expecting a lot of users to synchronize through it.
Second problem: Not enough marketing.
Yet another idea : A reddit tip bot.
Reddit crypto tip bots are really popular, and there are plenty of them to serve as base to make one, such as this one : https://github.com/normpad/iotatipbot/tree/master/ . The concept its easy and its just like a miniature exchange.
In fact, i wont lie, i'm working in one at the moment, but i don't really have any 99% uptime server that can easily run a wallet, so if anyone it's interested on buying it you can start the bidding.
GRC is just so suited for a system such as that one, considering the extremely small fees, and the high amount of users with very small quantities of the coin .
=======================================================================================
This post was upvoted by Steemgridcoin with the aim of promoting discussions surrounding Gridcoin and science.
This service is free. You can learn more on how to help here.
Have a nice day. :)
One other idea that I have, which I believe it was also in the mind of the first people starting with Gridcoin, would be to enable also sponsored projects in the white list. I can imagine there is a demand of computing power (CPU & GPU) that could pay GRCs in order to get their project accepted in the white list. This will create a demand for GRCs, and over time, it will increase the value of the Gridcoin.
similar: https://github.com/gridcoin-community/Gridcoin-Tasks/issues/208
Not to sound rude but this sounds like an extreme case of centralization. Who controls the "master server"? What happens if they are a malicious actor?
This is almost exactly what we have now. You can run a listening node even without a static IP, you just need the port forwarded.
By default, if a node has not received a block for a half hour it will request blocks from other nodes (I think). And you can always use the "Download Blocks" feature. I understand that this can be kind-of slow, but there has been a little bit of discussion in the slack on hosting our snapshots as consensus-generated torrents, instead of on the gridcoin.us server.
it doesnt run in the blockchain. Its a supplement to blockchain. It just synchronizes the data using rsync. It could be compromised, but if a bad actor took control of it, it would still have to spread to 51% of running nodes. Which is extremely unlikely. Think of it as a more elegant and efficient solution to download blocks.
I also like the idea of torrents, but i think that approach is actually vulnerable to being taken over malicious actors.
Only a Idea of a Concept(I dont think its easy to Implement)
I would personaly like more a System in the Wallet that lets say every day/960 Blocks try to find Consensus(hash of the blocks)of the Days befor... If the Package of the blocks is Approved for maybe 30Days/29k Blocks, it can be Propagated over somethink "Torrent like".
The block syncing is not slow because of the transfer protocol, but due to block checking. Every received block has to be verified and properly attached to the local blockchain database. It would take almost the same time to import blocks from rsync downloaded bundle.
Also any centralized server is highly suspicious.
Please add your suggestions to Gridcoin-Tasks repository.
Stefan @crt has offered a server capacity to the Gridcoin community. He is also developer, you should team up.