Hi, Rob:
Thanks for the detailed reply.
Kudos for all the great work done by the development team.
I believe what you guys are trailblazing here will have fundamental impact on the network in the future not just Gridcoin.
For example, in the future, a central network administration (such as BOINC team) can be replaced by the gridcoin p2p network with POW/POS built-in.
BOINC becomes of an Apps store. Even such Apps store can be distributed as we can securely store certificate and links of the Apps in the p2p network which allows people to download from authenticated apps location.
It may help if your visionary plan can be translated into a marketing campaign.
It will also help if there are derivatives of Gridcoin in the pipeline as part of the roadmap. Not to dilute Gridcoin, but to expand into different area and then provide additional value of the main coin network.
Would love to help if any is needed.
John
Hi, Grid:
If I understand correctly your new SQL based p2p crypto-exchange mechanism can be used as an effective Proof-of-Stock mechanism.
This may be even superior than Datacoin where they allow storing of some amount of data in the blockchain.
Can you shed some light on the differences?
John
I'd like to roll out SQL in phases:
* Client synchronization for standard data, blocks, tx, leaderboard - existing information that we can use for transaction auditing - all info can be harvested from the existing chain
* Full p2p distributed ledger: In the future, the ability to roll out data structures that are fully replicated and synchronized among our p2p network automatically.
* PoW (or PoS) based on the dissemination of the data itself. Useful for CPU miners and for validating the integrity of the data (rejecting any injected data not approved by the network)
We have partially finished #1- you can query blocks and credit information from boinc.
#2 and #3 requires an expanded SQL spec; replicating the schema is fine, but Im working on the mechanism that secures the synchronized "official" ledger state.
From a high level, I think if we roll out a cryptographically strong formula that locks each row to a block key and block time and rowhash, and prunes old data, it would work.
The process itself of creating the rowhash may be the key to the PoW required for SQL replication; For example, if it takes time and effort for a client to generate the rowhash for new data, that is part of the PoW required to add info to the sql tables in order to be accepted by the network.
Yes, in theory, the SQL future features may not only be able to store useful data for the coin (such as the data you referring to) but we may even be able to set up pointers to
web resources to store things like files that everyone can download - obviously to resources that have no point of failure and no central authority; etc; but Id like to focus on the SQL replication first.
Thanks,
Grid
