Yes I agree.
But we need dev?
There never has been "a dev" engaged in the project as such, at least not in the usual type of "resident dev/team" model that most altcoins follow. It might help if you think of deepcoinbiz as the equivalent of a movie producer - organises funding, logistsics and ad hoc commissions of specialists to perform specialised tasks as and when needed.
As far as I can make out, deepcoinbiz commissioned Peter Bushnell (
https://github.com/Bushstar) to create the clone (
https://github.com/Deepcoinbiz/Deepcoin/commit/66ef7fefe8da3cbebf0e7e48486877b2e45c5773) and do further development work, including implementing a change in algo (
https://github.com/Deepcoinbiz/Deepcoin/commit/0b8c28067c210e5c54bb48b264f70c8739fc7d9e) and and subsequent revisions (
https://github.com/Deepcoinbiz/Deepcoin/commit/1a926a7e7c41cfc01f60d3a3c7791c7316effe11). There's also a nearly-complete "stealth addresses" branch (
https://github.com/Deepcoinbiz/Deepcoin/commits/new-sx-0.8.7).
I don't find it profitable to speculate about this past phase of development, I'm interested only in its impact on the here and now. I believe Peter is open to commissions but that doesn't offer a resolution to the question "we need dev?" That answer to
that question lies in uncovering the group's collective understanding of the role fulfilled by "the dev".
I'm afraid that I'm prone to asking "difficult" questions such as "Exactly how much dicking about with the Bitcoin codebase do you think is actually needed to support your clone?" Okay, Dash's masternode system is complex enough to require a resident dev/team but it's a far less compelling argument when the clone is almost identical except for the algo and the emissions/reward schedule.
Hence:
https://github.com/gjhiggins/deepcoincore, a work-in-progress of transplanting the Deepcoin-specific elements into a Core 0.16 codebase. The rebranding is trivial, the actual first step in the process of discovering the reality behind "well, just how hard can it be?" is to replicate the genesis block and then read the blockchain. I'm halfway at the moment. The genesis block is correctly replicated and the Core 0.16 client reads the blockchain up to the hard fork at 76800. Then there's a sequence of 10 blocks for which the difficulty is calculated differently in order to prime the backwards-looking NiteGravityWell difficulty modifier. And that's not happening, which is what I am currently investigating.
So, if you fancy a play, check out the sources - careful to
git checkout deepcoin and compile it up. To generate yourself a readable bootstrap.dat of blocks 0-76800, apply the following changes to the current client's
contrib/linearize/example-linearize.cfg to get yourself a
linearize.cfg to use.
--- contrib/linearize/example-linearize.cfg 2018-09-03 14:44:38.565498248 +0100
+++ contrib/linearize/linearize.cfg 2018-09-05 19:03:34.731773981 +0100
@@ -1,12 +1,12 @@
# bitcoind RPC settings
-rpcuser=someuser
-rpcpassword=somepassword
+rpcuser=deepcoinrpcuser
+rpcpassword=deepcoinrpcuserpassword
host=127.0.0.1
-port=8332
+port=22872
# bootstrap.dat settings
-netmagic=f9beb4d9
-max_height=279000
+netmagic=aebfc0d1
+max_height=76850
output=bootstrap.dat
Then run
./linearize.py linearize.cfg, copy the resulting bootstrap.dat to the
datadir of your choice and fire up the client. Wait while it reads the bootstrap then clean out the datadir and try it again with a bootstrap.dat of 0-76801. Check the debug log for the rejected, out-of-order block. That's where I'm at.
I'll post notes on further progress as and when I manage to make any, assuming no-one else figures it out in the interim.
As far as I'm concerned, the answer to "Exactly how much dicking about with the Bitcoin codebase do you think is actually needed to support your clone?" is ... "As little as possible."
I'll throw this is in, in case I haven't mentioned it before:
A different perspective on cryptocurrency, with the challenge - if I
do manage to upgrade Deepcoin to Core 0.16 - what comes after that?
Cheers
Graham