Not thus far - I'm confined to a i7 laptop atm and given it's an expensive Dell XPS 15 9560, I'd rather buy than fry.

It should work out of the box, I've even forked the Gapcoin-PoWCore repos so's I can fix the constexpr issue which was preventing successful compilation.

Assuming the requisite packages are installed according to build-unix.md (https://github.com/gjhiggins/gapcoin/blob/v0.9.3-gap/doc/build-unix.md#to-build-from-git), the following should work out of the box for anyone wanting a GUI client on one of the current Ubuntu-flavoured distros:


The next significant task is to get the tests working (some of the test fixtures are Bitcoin-specific and are bound to fail).

You've not missed much. And Slimcoin, like Peercoin, remains PoS v1 which means you don't need the wallet open all the time to stake, just fire it up and wait while it grinds through the stakes.

Cheers

Graham

50 merit awarded, per pro (hope you don't mind).

FWIW, I've spent some time with the Gapcoin source code, upgrading it to use OpenSSL 1.1 (so it now compiles on contemporary Linux versions). I took the liberty of reverting the egregious irrelevant changes to the source code caused by j0nn9's over-eager regexp (https://github.com/gjhiggins/gapcoin/commit/551b27b55f9360d5788c047573f41122ddbfb53e) because only a few delicate changes are actually needed to do the job and there are distinct benefits from having a close match, not least in terms of making it easier to take advantage of upstream developments. In consequence, I was able to merge the Bitcoin Core 0.9.3 and Bitcoin Core 0.9.4 upstream releases (https://github.com/gjhiggins/gapcoin/commits/v0.9.3-gap). This work has been done in a separate branch "v0.9.3-gap" in my own forked repository on Github - https://github.com/gjhiggins/gapcoin/tree/v0.9.3-gap

Also, I am working on some GUI improvements/enhancements, again in a separate branch which I hope to commit to the repository towards the end of the week.

Cheers

Graham

I suspect the bchain.info operator (Markus Tervooren) is hosting the Slimcoin blockchain for his own reasons. If any Slimcoin hodlers wish to show concrete support, there's an LTC donation addy. The chainz explorer is hosted on a straight commercial basis, the hosting fee is 8.90€ per month and, as of today, there are 4 days left on the meter.

It's just whitespace - P4Titan's IDE automatically reformatted every file he edited from 4-space tab indentation to 2-space tab indentation, removed all the spaces between if, for and while tokens and the following parenthesis, e.g. if (foo) to if(foo). To me, that smacks of the typical posturing dogma of "I'm a real programmer" that ironically betrays just the opposite. I've reverted his IDE's auto-applied changes to the codebase to bring it back into conformity to the original coding style/format (ditto for the QtGui code).

I realised it was a pointless exercise and turned it off - the network conditions for testnet do not in any way replicate the network conditions for mainnet and so it is impossible to draw any reliable, well-founded conclusions. As regards testing a different staking regime on mainnet, well that option is wide open to any node owner whether they be blackhat, whitehat or greyhat.

As far as I could tell, the hard cap client seemed to simply stop all staking permanently. Unfortunately I don't yet have a good understanding of staking behaviour, so I wasn't able to conclude anything useful. Instead, I returned to using a standard client (compiled from master) and it's been running happily for a couple of months now. I had to stop-and-restart it a couple of times when it froze up during the recent network instability but the restarted client synced up straight away and, now that the network has settled down somewhat, the client is running fairly economically (for Slimcoin, that is) using between 10-15% of its allocated thread. The last PoS minting was on 2019/10/19:  and the last burn minting was on the same date.

Cheers

Graham

No need, the chainz node is now synched.

Cheers

Graham

It has been a bit bumpy, both my develop and master clients discovered they'd lost touch with the network, suddenly reporting that they'd found themselves several hundred blocks behind. I stopped and started them both, they synced up without problems, seeing stake and burn rewards. chainz client seems to have suffered the same problem, a simple restart might well fix it.

From the Heztner-hosted box' `getpeerinfo`:


Cheers

Graham

No, I meant muf18 who spent weeks of his time searching out and talking to various devs, trying to find any interest in taking on the legacy Slimcoin codebase, unfortunately without success.

Cheers

Graham

May I gently discourage such ungrounded off-the-cuff personal speculation, it tends to muddy the waters for others and takes time and effort to dispel.

Several community members have already put a lot of personal time and effort into exploring this route without even a hint of success. I'm not aware of such a pool of low-cost developers, (not that the apparent going rate of around 2% of the distro is all that low-cost) so it'd be down to you, as the proposer of such an initiative, to identify a candidate team and research the development schedule, costings --- and management --- and then present a worked-out initiative for community support. The inconveniently problematic issue of software project management tends to get completely ignored - but the need doesn't go away, these are real-life tough problems and some idea of a detailed solution needs to be developed in advance.

The other massive showstopper is that the community does not have access to adequate fiat resources to fund such a project. Even something as basic and crucial as funding the chainz block explorer is done on an ad hoc, personal basis. I stumped up for the last six months' hosting which is due to expire in a couple of weeks.

To get some sense of the ground-floor issues of open source software systems management, you could have a go at drumming up some BTC support for continued chainz explorer hosting. Judging by the activity of the top wallets, there are some active holders of significant quantities of SLM (https://chainz.cryptoid.info/slm/#!wallets) who should be motivated to take vigorous steps to protect their hodlings - unfortunately they seem oblivious to anything other than how many SLM they hold and are apparently careless of the actual worth of the tokens.

Who's the "we" that has the technical capacity to do this? Unfortunately, from a developer's perspective, it's both socially and economically unattractive in terms of personal time/effort vs ROI, it would be much more lucrative to simply launch one's own coin.

Cheers

Graham

Unfortunately, restitution can't be automated, has to be done painstakingly by hand. There's over a hundred files of source code involved so we're talking a few days' work. And that's just to re-style the code. I estimate that actually handling the merges up through 0.5, 0.6 and 0.7 versions of Peercoin would take several weeks/months.

Peercoin 0.5 had three/four versions but descriptive summaries are hard to find (https://discuss.nubits.com/t/merging-peerunity-with-peercoin-v0-5-2/3628):

Peercoin 0.6 Release notes: https://medium.com/peercoin/peercoin-v0-6-release-2831fb4394ad

Peercoin 0.7 Release notes: https://medium.com/peercoin/peercoin-v0-7-released-e4a5d4b3e517

Peercoin 0.8 Release announcement https://talk.peercoin.net/t/team-update-32-peercoin-v0-8-codename-mantis-release-announcement-upgrade-deadline-october-1st-2019-hard-fork/9515 (completely out of scope for Slimcoin atm)

Crucially, whilst the Slimcoin codebase may be directly derived from Peercoin, the respective communities and their ethos differ appreciably: https://www.bdratings.org/l/peercoin-an-old-tardigrade/

Cheers

Graham

P4Titan's idiosyncratic choice of coding style (https://github.com/slimcoin/slimcoin/blame/master/doc/coding.txt) is a major obstacle for anyone trying to merge/upgrade from Peercoin. The git-merge algorithm is unable to cope with the excessive number of discrepancies introduced by the resultant whitespace and syntax mangling. Just try merging Peercoin 0.6 into slimcoin-develop and you'll experience the scale of the problem for yourself.
 
Cheers

Graham

Have done.

Cheers

Graham

Hi jc,

Sorry for the delay, I've been offline for the last three months whilst moving house. I've updated the 0.9 repos and VCoin 0.9 now compiles on Ubuntu 19.

I don't know anything about the pool, I'll have to see if there's anything I can turn up.

In addition, the vcoincore repos has also been updated (to Core 0.18.1). ATM, I'm trying (but failing) to get a VCore 0.18.1 testnet up and running so's I can address the remaining significant unresolved technical issue, that of getting the metadata explorer to work more reliably with the client in respect of re-orgs. The 0.18.1 client compiles and runs, it even happily loads a copy of the current 0.9 mainnet datadir (very encouraging), it "sees" the other 0.18.1 clients on my internal testnet network and it can generate blocks but they don't seem to get broadcast to the testnet network. I'm still investigating.


Cheers

Graham

Thanks for reporting the -levent_pthreads thing, looks like this exercise is resulting in some more accurate and up-to-date compilation destructions.

As for the madpool support libs, I couldn't find anything specific in his posts but I 'spose it's mentioned somewhere that on Linux systems, you need to install another system library - sudo apt install libczmq-dev. (IIRC, to get this to work on Mint, I first had to correct a dependency mismatch, had to uninstall libczmq and allow apt to install both libczmq4 and libczmq-dev, YMMV).

Cheers

Graham

For wallet compatibility, Verionum was linking against his own compiled version of BerkeleyDB 4.8, probably on a modern Linux distro whose system packaging only provides a later version.

If you wish to take the same approach, it is well-described in the  "build-unix" cloneparent documentation.

The approach is optional, you can omit the -L link and -I include flags if you wish to use the more modern version of was-Berkeley-now-Oracle-DB that is installed by your system package. Do retain the CPPFLAGS="-fPIC", it's needed in order to satisfy the requirements for linking against the Qt libraries.

Cheers

Graham (11 days to go)

Uh-huh, take notes as you go and record the process this time. -lprotobuf is required, just as it was previously.

Cheers

Graham

Like you were the last time?

https://bitcointalk.org/index.php?topic=2188160.msg35249276#msg35249276

Cheers

Graham

A known issue, see upthread: https://bitcointalk.org/index.php?topic=2188160.msg46548383#msg46548383

(We're moving house and need to be out of here in two week's time so this is likely to be my last post for a few weeks.)

Cheers

Graham

Following on from my last post, I've been collaborating with DataSea on an "in wallet file publisher and file retriever for the block chain". That's the significance of the block explorer reporting the size of the stored data. It can "see" the data, so could be programmed to decode it and, if the mimetype of the resulting binary data (an apparently random sequence of 1s and 0s) can be accurately characterised, display it. Then there's some hope that a file retriever might be feasible.

The problem (of a crippling lack of metadata) is something I failed to communicate clearly enough to Verionum. It's reasonably trivial to hack up a Python script to reveal the state of play simply by iterating over all the txs, logging what it finds:

I constructed a preliminary log (available from mega.nz), the contents of which follow this format:

block='18587', tx=1, size=16, magic=text/plain,
block='19850', tx=1, size=4, magic=text/plain,
block='19990', tx=1, size=4, magic=application/octet-stream,
block='19996', tx=1, size=24, magic=application/octet-stream,
block='19997', tx=2, size=24, magic=application/octet-stream,
block='19997', tx=3, size=24, magic=application/octet-stream,
block='19997', tx=4, size=24, magic=application/octet-stream,
block='19998', tx=1, size=24, magic=application/octet-stream,
block='25030', tx=1, size=76, magic=application/x-bzip2,

Out of the total txs recorded on the Datacin blockchain (an unknown number but obviously equal to at least noofblocks, i.e. 3,018,698), there is a grand total of 8243 txs that store data on the Datacoin blockchain. Of those 8243 txs, the overwhelming proportion is of text/plain entries from years ago, carrying (now bitrotted) torrent urls in JSON format:

---

[{"datetime": "1394508689", "version": "0.1", "uploads": [{"host_name": "zalil_ru", "error": true}, {"url": "http://rghost.net/52974353", "host_name": "rghost"},
{"url": "http://ge.tt/6SxXzpP1/v/0", "host_name": "ge_tt"}], "filehash": "4feae9543dd945195b0ad16ff6bdf47bf8dd6d0cbbbb8aa04ede00e1c6e6a69a", "filesize": 58055}, {"datetime": "1394543728", "version": "0.1", "uploads": [{"url": "http://multiupload.nl/TAKI54M1WF", "host_name": "multiupload"}, {"url": "http://gfile.ru/a4gAx", "host_name": "gfile_ru"}, {"url": "http://rghost.net/52983046", "host_name": "rghost"}], "filehash": "cef6b6655166dc4b38e6488fcd2f6a63793a1859555978b700cadbc1cb4802b5", "filesize": 409569}]

---

(Latterly, the chain has been storing only asset and notarisation data):

---

ASSET:{{{{{md5 => c9d89438361ce6ed1fce8f7c50a9a92a, owner => DTC:D8GafEsbyssg4TQN71KTbd8QdRg846MxCQ, inputtx => FirstIssue, previousowner => DTC:D8GafEsbyssg4TQN71KTbd8QdRg846MxCQ, idop => JIE1}, prevownersign => H5OkR1dpSl0jfvRqfmmFw45SsG015RVF0AN+k1HZ40DHVtCHxuMAE60HLmQ3rmW1FS3/tHdsCLsGeHffNhPWfrE=}, bytestampsign => IGJWfWswMuPkbRx5BcErqFNDgygcdjTaCz4UmNcxEYjTdHmZMRtZN2nbO7KkzmkRH5DXt7tU0eGth8x khtXtrkY=}, prevhash => 39b8c8baa6cfe1c370816175265f71ab}, hash => a75f1175388b2ccbe4325284af5a1587}

---

I dumped everything that reported as "text/plain" into a (3.5Mb) text dump, one entry per line (also available from mega.nz), the first few lines of which are (output by Python as bytes format):

---

b'Hello Data\n'
b'\x86(b'
b'Test message...woooooooooooooooooot!\n'
b'\x8aY^\x81\xa9'
b'Hello DTC community, my name is mstfck. Pool software and mining software developer!'
b'https://cryptopush.com : Bitcoin Markey Alert System\n\n'
b'https://krypte.NET\r\n'
b'https://krypte.NET\r\n'
b'https://krypte.NET\r\n'
b'https://krypte.NET\r\n'
b' _  __ ____ ___  _ ____  _____  _____   _      _____ _____ \r\n/ |/ //  __\\\\  \\///  __\\/__ __\\/  __/  / \\  /|/  __//__ __\\\r\n|   / |  \\/| \\  / |  \\/|  / \\  |  \\    | |\\ |||  \\    / \\  \r\n|   \\ |    / / /  |  __/  | |  |  /_ __| | \\|||  /_   | |  \r\n\\_|\\_\\\\_/\\_\\/_/   \\_/     \\_/  \\____\\\\/\\_/  \\|\\____\\  \\_/  \r\n                                                           \r\n\r\n'
b'"Peace, Montag.  Give the people contests they win by remembering the words to more popular songs or the names of state capitals or how much corn Iowa grew last year.  Cram them full of noncombustible data, chock them so full of \'facts\' they feel stuffed, but absolutely \'brilliant\' with information.  Then they\'ll feel they\'re thinking, they\'ll get a sense of motion without moving.  And they\'ll be happy, because facts of that sort don\'t change.  Don\'t give them any slippery stuff like philosophy or sociology to tie things up with.  That way lies melancholy.  Any man who can take a TV wall apart and put it back together again, and most men can, nowadays, is happier than any man who tries to slide-rule, measure, and equate the universe, which just won\'t be measured or equated without making man feel bestial and lonely.  I know, I\'ve tried it.  So bring on your clubs and parties, your acrobats and magicians, your daredevils, jet cars, motorcycle helicopters, your sex and heroin, more of everything to do with automatic reflex.  If the drama is bad, if the film says nothing; if the play is hollow, sting me with the theremin, loudly.  I\'ll think I\'m responding to the play, when it\'s only a tactile reaction to vibration.  But I don\'t care.  I just like solid entertainment."\r\nR. Bradbury, Fahrenheit_451'
b'greg is awesome'

---

(Nice to see SF classics respected and way to go, greg.)

I then created a summary of the findings (block hash, tx index, mimetype) of those entries that had mimetypes characterisable by the Linux file utility (about 150 of 'em) which, in certain cases, could be retrieved and displayed (although do note that "ddi" is a disk image format). The summary is available as Python bindings (again, also available from mega.nz):

---

categorised = {
    "646265ab6761a19a179997ef49ee9bb68b7b0804790bf1069177d01a57c1127b-1": "pcx",
    "7a4bfe2095c4f6e033a40302f43799ff7dcb61ffbc4ac11f1d3a7ebc7ab95d3e-2": "vdx",
    "7dd4818994156ec6e11e51d00fa3e47ff0eb2dbaffcf5d536bccdb783d5f07cc-1": "pcx",
    "a1d413ad368b22274bcec6af50fb0e6a8de19e4efa2250d54f8955b50b7b3776-1": "rby",
    "a2720d3d85726ecb94d9feb02eab108bb47072fc2b283df18109467d4f385571-1": "mzx",
    "af27e7daf5c9178448526bea3ac83a1a27bd51da90933cfd202249b387936bab-1": "mov",
    "b32f973a0a3863ce5eb38f80cfc77a67555ae3ae19020ca5871158e4eab2377f-1": "pcx",
    "c91e8f9ea7c0ff210a3ee3e1f48079a8e2961ed99f180c2c3c4d9876edba3027-1": "vxd",
    "f0da6aae8347041d4cf080c93439e1af4e27639cf6546856ae7789d3b564bd63-2": "pgc",
    "fa6483b4d8a4a9d8f6573ecdf5a134b36686d7d2047042c4d115fb61f1f32bad-3": "dbf",
    "0510db4e73b38a16fde66ad8d5328e806d769930153591eb432ec79194c3f526-1": "ddi",
...

The "mov" is the only instance of Datacoin-blockchain-stored erotica (doesn't qualify legally as "pornography", AIUI) to be revealed by this analysis (5-10s of a couple doing it doggy-style, copied from a pron site - sadly more of a token gesture than any kind of an attempt at a public-spirited free pron service).

and a very much longer list of "uncategorised" of which all I know is i) its size and ii) its broad mimetype, for which characterising in further detail would require individual examination (but is rather unlikely to receive any):

---

datafiles = [
    dict(block='4c6dac1ec6c5131994a47d5a020adf2ef968222be88cc4a761ff283658c4af92',
           txid='39d542f56622d57a09f4e6bc05ce1abbb63e24430e71c26c03d3781a33afb302',
           n=1, size=16, mimetype="text/plain"),
    dict(block='92e53a0dd19486361404a7275dd9645ecbecddb0fd7f270eaa2cab79b427ca2b',
           txid='fc52b5f7a71bcbbe695e6edff94d6fd6e764b49023fe756f3e77366503befca8',
           n=1, size=100, mimetype="application/x-bzip2"),
...

---

In the event, I recoursed to dumping the text/plain entries into a single dump (see above), uncompressing the obviously-compressed (a mere handful) and assigning them accordingly (some images, some plaintext). This leaves around 2000 entries (i.e. the overwhelming majority) which are basically impenetrable from a practical perspective. Only those that created the tx know what it is they have stored. Maybe they will publish details of their format, maybe they won't. In some cases, a large binary has been split over several txs and has to be recombined to form the original single large file. Unfortunately, the inscrutability of "application/octet-data" gives no clue as to whether the binary is standalone or part of a sequence to be recombined and, importantly, which part of which sequence. None of this metadata is made available, so file retrieval cannot be offered for the vast majority of the chunks of binary data stored on the Datacoin blockchain txs.

Nevertheless, I intend to add the summaries to the clone of ACME that I have for Datacoin.

ACME? A Cryptocurrency Metadata Explorer, an open source project in Python, a web app (built using Pyramid) fronting an instance of Fuseki hosting a mapping of the blockchain/txs/addresses as an RDF graph (it's a mapping because the blockchain is characterisable as an acyclic directed graph and RDF is similarly characterisable as a directed acyclic graph). The RDF graph can be queried (by SPARQL queyr) and the results displayed appropriately:



Yes, this is stuff I've been working on for a while now. You may get some idea of the power and flexibilty of this technology by browsing the DOACC documentation (details of altcoins represented in RDF, put to rest in early 2016 when altcoin launches stopped including dereferencable URLs in ANNs) which is about the RDF representation of metadata pertaining to individual altcoins (and the datasource for the altcoincheatsheet I referenced in my previous post). I'm only suggesting it because you'll likely to be broadly familiar with the content (altcoin stuff) and that will provide a framework to appreciate the representational power - because it's a standalone site, all the RDF and SPARQL work you can see going on in the presentation and examples is happening in the browser.

Note the ACME "Publication" tab. That's where the summary data will appear, characterising the stored data and providing appropriate access. If metadata is available, the information can be presented:



And ACME is where TrustyURIs can resolve to. It's the next step I want to take. I have a candidate standalone, mostly self-contained (view source to see)  blog app-cum-post, nearly ready for storing on the Datacoin chain (I have yet to decide whether to bundle in a base64-encoding of the javascript and css resources, or just leave them (comparatively dangerously) remote and specify a validation hash).

I will render the HTML (and thus the content) as an RDF graph and then use the Python TrustyURI code library to calculate a hash of the RDF graph of the content, which can then be embedded in the resolvable TrustyURI inscribed on the blockchain. If the hash don't match, it ain't what I published. If the hash does match the resolved-to, ACME-hosted RDF graph, then its worth having a go at retrieving the content and rendering it.

The mechanism uses OP_RETURN data and is independent of any other uses, it's a sort of data storage that is tangential to Datacoin's use of a special field in the tx. Importantly, it's a form of data storage for which metadata (in the content such as <title>A different perspective on cryptocurrency</title>) can be made available on a principled basis (i.e. if the hash matches, show the metadata).

The other day, I mapped the Datacoin blockchain into RDF, grand total 36Gb (uncompressed, 7.6Gb compressed) serialized as ntriples. Next task is to slice that list of ntriples into bite-sized chunks to feed to Fuseki, then the Datacoin ACME's lights and switches should start working again.

Can I suggest that the content of the blog-app-cum-post  A different perspective on cryptocurrency provides some answers to your other questions.

Cheers

Graham
 

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

It would seem necessary  to include here the same admonition as I made to extro1: "I'd be insane to even appear to be taking responsibility for its correct functioning." The code is in a personal repository and has not been released, so I repeat:  I'd be insane to even appear to be taking responsibility for its correct functioning..

Just to make it crystal clear, I'll remind you all that these licensing terms apply:

Cheers

Graham

Not that I'm aware of (not that that means anything). And I'm hard-pressed to conjure up something that isn't already covered in the application documentation. Also, I think there's enough to take in already without adding edge-case technical administrivia. This particular example is constrained to a specific userland area - that of casual appeal to the community for assistance with trivial issues of compilation instead of RTFM, where the instructions are copy'n'pasta-ready:

https://github.com/nochowderforyou/clams/blob/master/doc/build-unix.md#berkeley-db

If the official docs are unread, that's just as likely to apply to any centralised resource.

Anyway, the issue of binary compatibility of wallet.db is only really an issue for distributors of proprietary OS applications (OS X and Windows - Linux users are free to choose which libraries are linked to) and, strictly speaking (this is cryptocurrency), the provision of binaries introduces security issues. Reflecting this, there is a supported/ing build system (https://github.com/nochowderforyou/clams/blob/master/doc/gitian-building.md) which is deterministic i.e. a hash of the resulting code binaries (Linux, OS X, Windows, depending on selection) will always be the same, so it can be cross-referenced against the published hash. All very open and verifiable.

Cheers

Graham