This has all come about because I wrapped up some playground work I'd been noodling on and privately advised some of the Datacoin community with whom I'd worked before.

That's the basics. There's some work-in-progress, adding some whistles and bells in the form of a Sign/Verify Encrypt/Decrypt tab and a half-adapted ripoff of Denariuscoin's "Proof of Image" notarization service and adapted as a "Proof of Data" tab, the block explorer showing the size of any data stored in a transaction and an additional field "inscription" in the sendcoins dialog box which uses OP_RETURN data to inscribe (by convention, TrustyURIs as) data on the blockchain. Not all of it is adapted/converted but most of it should work eventually.

In reply, I was asked about working on Datacoin 0.15.99, valued because of its much faster syncing speed - and you have already read my response. It's legacy code and that's a severe disincentive.

However ...

Rather unfortunately (from a hypothetical maintainer's/curator's perspective) Verionum published a series of tarballs of an edited copy (not fork) of Bitcoin master. A copy is  divorced from the principled record of serial changes to the cloneparent code known as the "commit history". So the Verionum github code repository has only 16 commits (https://github.com/datacoinproject/datacoin-core) instead of the >15k it would have as a fork. The commit history record is computationally tractable - and that's where the power kicks in. If the code is forked, it shares the cloneparent's history - and, rather importantly, can be upgraded from upstream contemporary changes. The process is called merging and, if Datacoin Core 0.15.99 could be re-connected to its Bitcoin commit history as a fork, then it would be possible to merge with (i.e. upgrade to) later versions of Bitcoin - in principle. In practice ... well speaking for myself, I can only give it a go and see how it turns out.

One of the problems is identifying exactly at which point in the Bitcoin commit history Verionum copied the code. Fortunately, there is a tell-tale: #define GIT_COMMIT_ID "13f53b750dc". I cloned Bitcoin locally, checked out the referenced commit, created a new branch and copied the Datacoin 0.15.99 code over. At that point, I switched back to a git GUI to process the changes that I'd made. I got everything working and wrapped it all up as a branch called "shim". The result is as extro1 enthusiastically advertised: https://github.com/gjhiggins/datacoin-core, with >15k commits. There's one significant difference to the Verionum version, shim has a block explorer - which shows the size of any data stored in a tx.

This is all personal research. I'm kind of interested in the architecture of Bitcoin clones, how they differ from Bitcoin itself. One simple dimension by which they can vary is the PoW algo (c.f. Groestlcoin, Skeincoin, Fuguecoin, Roulettecoin, et al,). The Bitcoin code is fairly modular, chunks of it can be relatively easily changed, swapped in/out - the PoW algo code is relatively trivially switched.  Back in '14, it was pretty much the major discriminator and claims for relative algo/combo "superiority" started to follow a bit of a pattern and, as that's the kind of thing that fascinates/motivates me, it resulted in a piece of web art, Minkiz' Foundry, a spoof altcoin template service offering a set of PoW variations, each with a clipped, concise pitch for the algo. (Yeah, okay, I do have an oblique sense of humor, see also Minkiz Hodlerscope - just type in the box and while you're there, help yourself to a copy of  the altcoin cheatsheet, an svg showing the entire population of altcoins back in March 2016)

It's not entirely a spoof, it sort of follows naturally from my understanding and exploration of the modular nature of Bitcoin code - behind the scenes, privately, the Foundry works. Originally published for Core 0.9, I've kept the templates up to date, i.e. Core 0.18. The thing is, when you work with templates, comparing the architecture of different altcoin codebases is easier because a whole host of irrelevant-but-distracting differences (such as coin name) just disappear, revealing the key differences in the functional architecture. Quite an informative exercise (to someone interested in the form of architectural variations).

Couple this with the fact that the Bitcoin Core 0.16 release was picked up by a number of what I'd call "senior alts", including Namecoin, run a few comparisons across templated versions of Bitcoin Core 0.16, Namecoin Core 0.16 and Datacoin Core 0.16 and an opportunity arises. Datacoin does its data biz by adding a data field to the standard transaction. Namecoin does its name biz by looking at OP_RETURN data. The two variants do not interact so might well co-exist, which lends some support for extro1's earlier conjecture as to the possibility of adding Namecoin domains to Datacoin.

Just out of curiosity, I'm exploring the issues attendant on merging/upgrading the Datacoin 0.15.99 code to 0.16.2 (a pre-requisite for the inclusion of any functionality filched from Namecoin). It's not straightforward and right now I'm in the middle of moving house, so I'm unlikely to be able to put significant effort into personal research for a little while.

I'll try and answer your other questions in a following post.

Cheers

Graham