Someone is burning a lot of cycles mining Datacoin.
In the past 24 hours, we have jumped to a difficulty of 7.3 and blocks are being found several times per minute.
In the last 24 hours, 4396 blocks have been minted.
I'm responsible for
some of that (126 blocks by the look of it):
/www/lib/abe/datacoin-hp/datacoind listtransactions "" 1000 0 | grep amount | wc
126 378 4032It's a Hetzner-hosted server and I'm using cron to enable one i5 thread's worth of
setgenerate true for 10m twice per hour, e.g.
51 * * * * /www/lib/abe/datacoin-hp/datacoind setgenerate true 1
0 * * * * /www/lib/abe/datacoin-hp/datacoind setgenerate false
Don't be misled by the
/www/lib/abe/datacoin-hp, I'm not working on adapting the Abe block explorer for Datacoin.
What I
do have is a nearly-complete ACME adaptation. ACME stands for “A Cryptocurrency Metadata Explorer” and it's an idiosyncratic, in-development approach to extracting and presenting the metadata associated with blocks, transactions and addresses.
There's an early version on Minkiz ...
https://minkiz.co/acme/dtc but the displayed metadata is confined to what can be retrieved using the existing JSON-RPC commands, the “regulation dance moves” (if you're familiar with Dan Houser's work “In the Future, there Will be Robots” in GTA VC).
The basic issue is that the wallet itself is basically a transaction browser, scoped to transactions pertinent to a given set of addresses (i.e.
yours) and so that version of ACME returns an error when attempting to retrieve the metadata associated with an address because there are no JSON-RPC commands that return the desired data.
As a consequence, in order to access metadata pertinent to addresses, one must create a separate representation of pretty much the entire blockchain in a form that can be searched, e.g. a standard database (the path followed by Abe, Iquidus, et al.)
It transpires that the blockchain is mostly metadata (txinhash, txohash, addrhash, blockhash, merkleroothash, dates, difficulty, nbits, nonces, etc.) and, as has been observed elsewhere on bitcointalk, the blockchain is a
directed acyclic graph.
My familiarity with semantic web enables me to understand that a directed acyclic graph can be straightforwardly
mapped to an
RDF model (a labelled directed multigraph).
That is to say, I have a small Python script that maps the metadata returned by JSON-RPC calls on the client, e.g. this is the response for block #1 of Slimcoin's testnet ...
{
"Formatted nEffectiveBurnCoins": "0.00",
"bits": "1e7fffff",
"difficulty": 3.052e-05,
"entropybit": 1,
"flags": "proof-of-work",
"hash": "000032dd80ce31e95065504b6d4b688497f9d5093b88ac617a676e61c726d9c1",
"height": 1,
"merkleroot": "be151c377da175c2a06e8d8e103575e27440c9819258a92dc80753d144d93019",
"mint": 42.04,
"modifier": "0000000000000000",
"modifierchecksum": "bc4b99b6",
"nBurnBits": "1f00ffff",
"nEffectiveBurnCoins": "0",
"nextblockhash": "0000624e33550d6a42ca7d48db2c4707d900009f8fd710b4b5444c8acaded7ff",
"nonce": 13988,
"previousblockhash": "00000d7e8a80fec4057cb6d560822705596040bf41f0ebb2465dcdf46e4c517e",
"proofhash": "000032dd80ce31e95065504b6d4b688497f9d5093b88ac617a676e61c726d9c1",
"size": 356,
"time": "2017-04-15 19:27:40 UTC",
"tx": [
"be151c377da175c2a06e8d8e103575e27440c9819258a92dc80753d144d93019"
],
"version": 1
}
mapped to RDF, the green bit, in this context-setting example, note how the (slightly decorated) hash identifiers map the RDF to the blockchain data. I've included some additional statements to illustrate the range of representation available:
@prefix : <http://purl.org/net/bel-epa/ccy#> .
@prefix doacc: <http://purl.org/net/bel-epa/doacc#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
:C00000d7e8a80fec4057cb6d560822705596040bf41f0ebb2465dcdf46e4c517e
a :BlockChain ;
:cryptocurrency doacc:D6b7dd05f-19f2-4b36-833d-f4bda4be58f5 .
doacc:D6b7dd05f-19f2-4b36-833d-f4bda4be58f5
a doacc:Cryptocurrency ;
dc:description "Slimcoin burn mining is truly ASIC-proof."@en ;
doacc:block-reward "50" ;
doacc:block-time 90 ;
doacc:date-founded "2014-05-28"^^xsd:date ;
doacc:distribution-scheme doacc:Dc10c93fb-f7ec-40cd-a06e-7890686f6ef8 ;
doacc:image "slimcoin_slm.png" ;
doacc:incept "2014-05" ;
doacc:pow doacc:D28483031-b854-4853-9a35-e1daf97e4c59 ;
doacc:protection-scheme doacc:D493eab2e-eeba-496d-afca-c9372c6efe9a ;
doacc:protocol doacc:Dede0f611-3a23-4794-b768-0740933a5ff6 ;
doacc:retarget-time "continuous" ;
doacc:reward-modifier "var/diff" ;
doacc:symbol "SLM"@en ;
doacc:total-coins "250000000" ;
skos:prefLabel "Slimcoin"@en .
:C000032dd80ce31e95065504b6d4b688497f9d5093b88ac617a676e61c726d9c1
a :Block ;
:difficulty 3.052e-05 ;
:flags "proof-of-work" ;
:height 1 ;
:mint 42.04 ;
:nextblockhash :C0000624e33550d6a42ca7d48db2c4707d900009f8fd710b4b5444c8acaded7ff ;
:previousblockhash :C00000d7e8a80fec4057cb6d560822705596040bf41f0ebb2465dcdf46e4c517e ;
:size 356 ;
:time 1492277260 .
[ ... ]
:Cd59670bd91b31ed6ec358bcce242a66ddce2fe8845e6dd7fdef4361ae9c583f9
a :Block ;
:difficulty 0.07415064 ;
:flags "proof-of-burn" ;
:height 184 ;
:mint 94.77 ;
:nextblockhash :C00000006874a6a4e3b9d91c52d34f2782e8728902d95277ba85758232bb66fdf ;
:previousblockhash :C00000006ecd2854d57e9469143e04bb77c457cf5766baefc953633ad79537eff ;
:size 355 ;
:time 1492287327 .
I haven't included the RDF for the transaction hash referenced in the JSON response
be151c377da175c2a06e8d8e103575e27440c9819258a92dc80753d144d93019but it can be looked up as
:Cbe151c377da175c2a06e8d8e103575e27440c9819258a92dc80753d144d93019, or to render it with a fully-expanded identifier:
http://purl.org/net/bel-epa/ccy#Cbe151c377da175c2a06e8d8e103575e27440c9819258a92dc80753d144d93019(This is a prototype, I can make the URLs work, the URLs can be changed to
http://purl.org/net/datacoin/ccy# on successful registration of a purl.org account and the successful submission of a /net/datacoin subdomain request - I got one for bel-epa as you can guess).
The Datacoin ACME running on
http://tessier.bel-epa.com, port 5059 (apologies for the apparentl coyness, Hetzner's outsourced DoS protection algos have a habit of misclassifying web traffic to “unexpected” ports as DoS attempts and closing access to the port) is (atm) only JSON-RPC but you can get an idea of a more complete version by browsing the Slimcoin ACME on
http://tessier.bel-epa.com, port 6054. Look at what's going on in “Publications” (on both mainnet and testnet - to toggle between them, click the coin icon/name in the menubar).
So, not just a metadata explorer but also, for Datacoin, the fact that ACME is a web app also means that it is also a vehicle that potentially can be made capable of detecting which txs have a non-null value bound to their “data” slot, what that value is and if that data has been embedded in a metadata-holding
protobuf structure which can be interrogated to discover the declared MIME type of the stored binary data and rendered appropriately according to the MIME type (in a vain hope that the mimetype declaration is actually accurate).
So, I have a JSON-RPC-only v0 of ACME, a v1 variant
developed for Slimcoin, a v2 variant of v1
adapted for Datacoin and my next task, before releasing the code as open source is create v0.0, the intersection of v0, v1 and v2, properly generalised (some altcoin implementations return dates as a formatted string, others return a timestamp-in-seconds integer). Then the Slimcoin and Datacoin adaptations can become separate branches (ditto for Beecoin, which is the next adaptation in the queue).
I don't see a dev, too centralised for my tastes. But I
do see custodians, curators and restorers. That's a good distributed thing and renders this peer-to-peer network more likely to (continue to) survive.
Cheers
Graham
