Will you publish the source code?
It's not strictly necessary, all the relevant code is Open Source - qubit_hash for the Python-C interface library and a fork of Abe that includes a general “QubitChain” class suitable for use with qubit-using coins such as the Cassubian Detk, Deepcoin and, allegedly, other new coins currently in development.
Details:
qubit-hash:
https://github.com/qubitcoin-project/qubit-hash - Python interface to C sources of sph lib
Abe:
https://github.com/qubitcoin-project/bitcoin-abe - (fork of) Abe, Python web app, with a QubitChain class
Commanding Abe to read the blockchain into the db:
python -m Abe.abe --config abe-dcn.conf --commit-bytes 100000 --no-serve
and, for the information required to create a suitable abe-dcn.conf ....
$ grep 'pchMessageStart\[4]\' Deepcoin/src/main.cpp
unsigned char pchMessageStart[4] = { 0xae, 0xbf, 0xc0, 0xd1 };
$ grep -e 'PUBKEY_ADDRESS =' Deepcoin/src/base58.h
PUBKEY_ADDRESS = 30, // Deepcoin addresses start with D
resulting, eventually in ....
datadir += [
{
"dirname": "/home/vagrant/.deepcoin",
"chain": "DeepCoin",
"policy": "QubitChain",
"code3": "DCN",
"loader": "blkfile",
"address_version": "\u001d",
"magic": "\u00ae\u00bf\u00c0\u00d1",
"conf": "deepcoin.conf",
"datadir_rpcport": "22872",
}
]
(In this instance, user is “vagrant” because I'm developing a flexible Vagrant+ansible deployment script that should cater for most variations: ranging from creating a fully-provisioned, cloud-hosted coin daemon+Abe instance to installing just Abe on an existing machine.)That said, I'm still trying to figure out why I can't seem to persuade Abe to synch Deepcoin completely up to date, which is why I haven't previously advertised the URL -
http://minkiz.co/abe/chain/DeepCoinGetting it working is only part of the process, there's stuff like process monitoring and disaster recovery to consider, reflecting Abe's new importance as facilitator of exchange listings. My view is that a coin should have several block explorers - they can act as nodes, bringing some much-needed decentralisation to the otherwise centrally-oriented DNSSeed and checkpoint nodes, known to cause problems:
The issue was with the checkpoint node being off-line and hitching onto an incorrect fork, where then it forced all other nodes to go to that fork since it is the checkpoint node. That incorrect fork was not caused by block propagation delays either, it was caused by the creation of PoS blocks. Since it has been off-line, the staked coins on it accumulated coinage. When the node came back on-line, it created a few PoS blocks immediately, before it synced up, causing a fork. Since it was the checkpoint node, the network was forced to that chain.
There's a thread for another coin that basically tells the story of when the dev of that particular coin hadn't commissioned enough resources to support the coin's single DNSSeed node, it got effectively DDOSd on launch, just like Mooncoin did, running on deacon boogie's home ADSL connection.
I've concluded that for a variety of well-supported reasons, a handful of explorers is a Good Thing(tm) to strive after as it tends to enhance stability of coin operations in the face of adverse conditions.
Cheers
Graham