The problem is that I'm almost sure that services like Coinmarketcap do not run their own altcoin clients (they would have to run about 1000 clients) and so they rely on a single point of failure anyway.
That's what I had concluded to be the only workable approach.
In which case, I'm going to make life considerably easier for myself and everyone else and halt the development work aimed at adding
moneysupply and
nburnedcoins to the db index because it adds unnecessary complexity to the client and increases the maintenance load of the codebase.
We already have a solution - the currently unusable-but-functioning
importaddress feature addition, implemented in the
watch branch with a single commit:
https://github.com/slimcoin-project/Slimcoin/commit/a8a9e698a320a04cc5cf0e98ce61bc8e3a87d99d, all neatly packaged for close inspection.
If you recall, I thoughtlessly tested it by importing the first address to hand, the burn address and the client went into paroxysms of fevered CPU activity, trying to calculate a stake for the 5000-plus tx history. Setting
reserveblance should cure that issue and a small HTML/JSON wrapper that publishes
getinfo on demand is what we're interested in because it will contain i) an accurate and direct report of the moneysupply and ii) an accurate and direct report of the total number of coins sent to the (unspendable) burn address.
The problem is reduced to that of maintaining a specifically-compiled Slimcoin node and a small wrapper. In the interim, I'll reconfigure the two Slimcoin empty-walleted clients that ACME interrogates (mainnet and testnet, both clients configured to use BerkeleyDB 4.8 to allow usable
datadir snapshots) to be watch-address clients tracking the mainnet burn address and the testnet burn addresses respectively. This will allow
nburnedcoins to be reported directly using the battle-tested client code instead of a report based on querying a less-than-reliable, over-complex SPARQL/RDF setup.
Using the above strategy (compiling a client for the
feature.watch branch), I will create a community resource devops solution that is as trivially deployable as I can manage * and I'll fund an initial instance for 12 months, that
should see us through the next stage.
Comments, observations, suggestions, welcome.
Cheers
Graham
*
https://groupon.github.io/ansible-silo/ <- docker-specific but that's okay
Furthermore you can bundle your playbooks (incl. configuration, roles, plugins etc) in a custom Docker image which inherits Silo and therefore generate a versioned, shippable, complete and self-contained executable package which runs your playbooks in any environment. (where you have access to a Docker daemon)