Find candidates for new Code Base

[tomasbrod]

Find the most developed, open-source and stable bitcoin-like Coin implementation for the #174 Sharedrop scenario. Can be PoW or PoS.

[grctest]

I disagree with limiting the search to bitcoin-like codebases, If I had to pick one I'd select graphene for the following reasons:

Links:
https://cryptocurrencytalk.com/topic/24622-dposbitshares-tool-kit/
https://github.com/cryptonomex/graphene
https://github.com/bitshares/bitshares-core
https://github.com/steemit/steem

Starting with the disadvantages:
* New codebase thus potentially large learning curve.
* A large amount of current code wouldn't be compatible & would require being ported to c++ (Though this is the case for rebasing to any codebase & we're already talking about rearchitecting).
* Not a short term development undergoing, highly plausible that the porting of the GRC features to c++ will prove difficult & time consuming (same applies to all codebase changes & we're talking of implementing improved GRC features in c++ anyways)
* Steem compared to BTS is quite different, so cherry picking ideas from one into the other would likely prove difficult.

Advantages:
* Uplift to a maintained codebase (though that applies to any new codebase we switch to)
* 10k+ transactions per second (TPS) proven on Bitshares, compared to our TPS in the single/double digit range. Fair enough we don't need this, we can tweak the settings to not mimic the performance of BTS (we could increase block timings, etc).
* Low stake weight concern would be gone - only elected witnesses would produce blocks & if unreliable they can be voted out by the network. Block producers would be trusted community members, not every token holder on the network.
* No need to continue development on current GRC issues such as POS Staking mechanisms, hardening/decentralizing voting, decentralizing permissions (beacon deletion & project registration transaction role that RTM held).
* Reduced quantity of users downloading the stats files each day (as opposed to hundreds to potentially thousands currently) eliminating DDOS concern without needing central proxy server.
* Witnesses could implement their own external BOINC statistics gathering scripts (with any preferred language), rather than a single solution being built into the client.
* Witnesses could publish BOINC statistics at will, similar to the current BTS price feed mechanism, negating the need for a daily superblock if we were to average the credit published by each witness when issuing rewards (perhaps at a scheduled time, or more frequent for users with more GRC).
* Graphene has an easily configurable UI & web wallet interfaces (which anyone can host).
* If we were to implement a similar distribution mechanism to steem (issuing additional tokens to users based on mag instead of votes) the distribution mechanism would be similar to the older cryptolottery system without the risk of manipulation.
* No initial investment requirement would ease recruitment of new users, potentially enabling automated BOINC + GRC client wizard setups.
* Clean blockchain slate - we've got old scrypt blocks & old blockchain data no longer in use (which we currently need to support to enable syncing from zero). - applies to any new codebase though
* If a fork of BTS: Issue tokens for projects, teams, etc & have an inbuilt exchange w/ GRC as the base trading pair (and token to power the network). 

[tomasbrod]

I requested bitcoin-like because it is the most simple. It has no extra features and provides a clean foundation for our features. In this case:

PascalCoin, very scalable p2p coin that as first features supports truncating the blockchain without loosing security. Also in my favourite programming language.

[jring-o]

I think there needs to be a list of 5-10 potential rebases. Should be ranked based on number of commits, number of contributors, number of issues/resolutions, marketcap, time in existence, team involved with original development -- are they still involved with development, [add requirements here]

list of benefits, list of drawbacks

[Mercosity]

I'm inclined to agree with jring-o on the list of potential rebases .. Perhaps we could find or create an understandable matrix with the ranking based on an agreed format as mentioned (number of commits, number of contributors, number of issues/resolutions, marketcap, time in existence, team involved with original development -- are they still involved with development) then it could be presented to the community in that format.

[Mercosity]

An interesting paper on this - tasca2017ontology.pdf

[TheCharlatan]

Bitcoin, is an obvious choice. I think I will list the drawbacks that I see first:

• Recently a bit slow when it comes to introducing new features. No cool truncating, sharding, or anonymity features.
• The core wallet is very simple and does not support many of the cool features that other wallets have, even though it would be possible.
• Need to change from Proof of Work to Proof of Stake
• C++ and Autotools is not everybody's favorite
• No delegate system we can bootstrap from

Some of these might prove to be advantages in the long run though.

• Since the Bitcoin development process is very strict, we can merge upstream changes with confidence.
• A simple core wallet also means, that it won't be too hard to implement our recent design changes again. Also it is easily extended with Gridcoin Menu Options without getting cluttered.
• The change to Proof of Stake gives us the chance to start with a completely clean basis. Very contrary to the current state, when looking at all the legacy kernels kept within.
• A delegate system, or Tomas' Dynamic Witness Participation proposal might take longer to implement, but in the long run advantageous, since we can start clean again.

Regardless the Bitcoin Codebase is time hardened and well documented. The codebase is quite modular. If a Gridcoin library were integrated, it would make merging upstream changes into Gridcoin again very easy. Bitcoin also sets the industry standard in transaction format, any 3rd party libraries or applications that expect this format, could then be adapted to be used with Gridcoin as well without too much effort.

Using the Bitcoin code base we can focus our efforts on the features that make Gridcoin unique, and can rely on merging changes done in Bitcoin to keep a stable and secure client.

[Mercosity]

Matrix pdf example, I have this in .ods format - Blockchain-Players-and-Feature-Matrix.pdf

[jring-o]

Will we be rebasing with the expectation of perhaps upgrading again in another year or so -- once some more technologies are developed? Or how does this thinking factor into the decision making process?