The current DTC code is very old.
Indeed it is. But importantly, it is a full clone of Primecoin and retains the prior commit history.
I can try to upgrade the code. Is it meaningful?
Yes, it is. The Primecoin codebase has been improved since the Datacoin fork. It is now at hp-14 (improvements to the speed). One route to upgrading Datacoin is by integrating those subsequent improvements. That's the approach taken by g1go in
https://github.com/g1g0/datacoin-hp/commits/master I'm looking to create a donation-free version by merging direct from the Primecoin commits. Not quite there yet. The work-in-progress is in
https://github.com/gjhiggins/datacoin.
May be I will try to support it. I need a list of necessary improvements.
Fixing up the test suite would be a useful start. That, in conjunction with enabling Travis CI (Continuous Integration) would bring a beneficial hike in the standard of software engineering employed in the curation and would help increase confidence in the reliability of the engine. Getting the speed up to HP-14 will be a significant achievement.
But I am a newbie in cryptocurrencies. I need the time for deep exploration of the original code and proposed improvements (if there will be any). It can take a month or more. Please write here if you are interested in.
Well, extro24 is also having a go at compiling the source, so it looks like we might have a small group of curators.
Please write the list of necessary improvements.
Is it possible to integrate some new cryptocurrency technologies into DTC?
I am looking into an alternative possibility, trying to develop a working understanding of the precise outline of Datacoin's footprint on the Primecoin codebase and how well (or otherwise) that might transfer to a more recent codebase. I've not made much progress, it's a labour-intensive process - as you observed.
And I'm in the process of completing an adaptation of ACME for Datacoin. ACME stands for A Cryptocurrency Metadata Explorer, a block and transaction explorer like Abe/Iquidus, etc, the difference being that ACME (transparently) maps the blockchain to RDF, with all the power that brings.
It's a rapid prototype built from hooking up a
Pyramid web app, a Datacoin node, and
Fuseki, the Apache Jena SPARQL server.
To get an idea of what this delivers, the first phase of ACME for Slimcoin is nearly complete, it's accessible on
http://tessier.bel-epa.com, port 6054 (be gentle, it's not yet optimised for delivery).
The Datacoin adaptation is in its early stages. The presentation uses calls on the JSON-RPC API of the node to get its block and tx data. Address data has to be collated off-chain because basically, a wallet is a transaction explorer, scoped to a set of addresses. The index maintained by the wallet is transaction -> address but to browse addresses, the index needs to be address <- transaction, hence the RDF+SPARQL with the added advantage that the RDF graph is replicable, i.e. publishable and amenable to ad hoc interrogation by means of SPARQL query.
I working my way through the blockchain in 20k chunks, mapping the block and tx hashes and data to RDF, then loading that up to the SPARQL server.
More by way of a teaser than anything useful at the moment, an instance of ACME for Datacoin is running :
http://tessier.bel-epa.com, port 5059. Again, be gentle, this is work-in-progress, for example, on the Publications->Chains page, the addresses listed against blocks with height > 400000 won't resolve because that's as far as I've got with the mapping to RDF.
The Pyramid app is maintained as branch of ACME:
https://github.com/gjhiggins/acme/tree/datacoinThe aim is to end up with a deployable package of a running instance of ACME with a synced node and RDF graph.
Cheers
Graham