Topic: [ANN][Datacoin] Datacoin blockchain start announcement (Minor code upd + logo) - page 8. (Read 171889 times)

Not everyone interprets that as a reliable indicator of success.

Cheers

Graham

Is Datacoin still relevant as we have other active projects like SIA, STORJ and filecoin with active dev team and lot of money to spend at their disposal?

+1.

Work on ACME for Datacoin is taking place in the datacoin branch:

https://github.com/gjhiggins/acme/tree/datacoin

It's an exercise in rapid prototyping (i.e. “I wonder if this might work?”), so it's very scrappy but it's reasonably straightforward.

It's a web app developed using the artisan-focused Pyramid web application development framework (which has the overwhelming advantage of being clearly documented) and so, in principle, can be extended arbitrarily by anyone with a degree of familiarity with Python.

The app uses some features of RDFLib (a (the) Python library for handling RDF) to map the block hashes, tx hashes, etc into an RDF representation which can then be uploaded to an instance of Fuseki, the Apache Jena SPARQL server.

SPARQL searches of the graph not only provide the address metadata needed for a complete metadata explorer but also allow of some UX improvements (currently only hinted at in Datacoin ACME) such as the ability to take a calendarial view of the chain state (i.e. the drop-down menu offers year/month access). Illustrations of network performance can be created (such as the plot of the diff for the last 100 blocks).

Once the graph is up to date, currency is maintained by the use of the client blocknotify facility to trigger a script which updates the RDF graph with the metadata for newly-received block/txs (don't ask me about re-orgs, I haven't even contemplated that).

The SPARQL server provides essential search functionality not available from the coin app's JSON-RPC command functions.

I'm currently working on improving the operation of the scripts which create the RDF graph and keep it current.

Testnet is only a few k blocks and locally, ACME Datacoin testnet is working as designed, next step is to check and create the mapping for the not-quite 2m blocks of mainnet.

The whole deal (coin app, blockchain, Pyramid app, RDF graph creation, Fuseki, etc.) will ultimately be released as a docker container for ease of hands-off deployment.

Datacoin ACME is a potential route around the metadata issue that (I perceive) is currently hindering the development of Datacoin. The “publish-by-OP_RETURN” feature introduced to Slimcoin suffers from the same quintessential problem - where to store the metadata needed for successful programmatic interpretation of an arbitrary sequence of bytes. ACME stores the metadata in a queryable RDF map of the blockchain.

To give you some idea of the flavour, the following query returns the height of the next block minted after the given date (unix timestamp)

# Date to blockheight
SELECT ?height ?dt WHERE {
    ?block ?height .
    ?block ?dt.
    FILTER (?dt < 1501282800)
} ORDER BY DESC(?dt) LIMIT 1

That's the verbose form (all URLs in full), normally a more laconic form is used:

# Date to blockheight
PREFIX ccy:
SELECT ?height ?dt WHERE {
    ?block ccy:height ?height .
    ?block ccy:time ?dt.
    FILTER (?dt < 1502314728)
} ORDER BY DESC(?dt) LIMIT 1


(2819, according to the testnet I set up a few days ago, so I  don't have a month-end date yet but you get the idea, I hope)


On the basis that, if it's managed to survive thus far, these days it's got a good chance of being a far more solid prospect than any contemporary ICO.

Cheers

Graham

Embii tells me (on Facebook) that they will look into verionum's suggestion for Apertus.io over this weekend.  They are starting with the next version of Apertus.io and I think we should follow the developments, especially as far as integration with Datacoin is concerned.

Biggest problem with exchanges is that they always ask "who is the developer?" and "where is the latest wallet?".  In future I am going to start naming the people in this forum who seem to be involved in the code or who have a Datacoin repository on Github.  People like Chicago, cryptrol, gjhiggins or verionum.  Please create your own Datacoin repositories and do pull requests.  That is really all the exchanges are asking for.  If you want to volunteer or object please say so.  Gregory Higgins has a list of exchanges here:  https://minkiz.co/exchange

Everybody please mine and run nodes.  I could get thousands of coins with old Celeron laptops.  Difficulty is now 7.61 and climbing, but that is much better than the 6.8 where we were.

I get the sense that with Bitcoin at $4000 people are highly motivated to look at the old and neglected coins like Datacoin.  Especially since you can do more with Datacoin than with Bitcoin.  Datacoin plus Namecoin is effectively an uncensorable Internet, with websites that cannot be seized or shut down.

It will be great if this coin comes back and be listed in some exchanges.
Bter delisted it for its risky of 51% attack due to the low hash.
Love this coin from the day it announced.
Thanks for all the effort you do and stay tuned.

Back in 2013 I found it really interesting, had 12 nodes runinng at some point and I guess I still can find the private keys of my wallet... should I rerun the nodes??

I smell teamwork.

Thank you for your insight.  I understand the Apertus.io team are now looking at it.

Ahhh, is that what it is. I couldn't figure out what the md5 hashes were about. Must be a similar approach, using the md5 hashes as indexes.

I wonder if the preceding binary is what protobuf gets boiled down to:

1. Only CompressionMethod and Data fields are required. Compression method can be set to "None" (means no compression).

from https://github.com/foo1inge/datacoin-browser/blob/master/perl/envelope.proto#L34

Unless bytestamp use their own scheme.

Cheers

Graham

It seems that transaction does not contain the original gif file. It seems it contains MD5 signature of the external file.

"TVJdLTBAXy9EV2MxZjRiZGFmY2M4Y2RmMTU0MDIxZjI4NzEyYzNkNjMzLDZmMDNiYjJhNGVlMzE4NzM 2YTc4OTlhZDI0MDVhNDE1LA==" is base64 encoded.


After decode "TVJdLTBAXy9EV2MxZjRiZGFmY2M4Y2RmMTU0MDIxZjI4NzEyYzNkNjMzLDZmMDNiYjJhNGVlMzE4NzM 2YTc4OTlhZDI0MDVhNDE1LA=="  
turns into     "MR]-0@_/DWc1f4bdafcc8cdf154021f28712c3d633,6f03bb2a4ee318736a7899ad2405a415,"

It perfectly corresponds to bytestamp's info of that transaction: "MD5 in this transaction: c1f4bdafcc8cdf154021f28712c3d633 - MD5 of the note: 6f03bb2a4ee318736a7899ad2405a415"


It seems that "MR]-0@_/DWc1f4bdafcc8cdf154021f28712c3d633,6f03bb2a4ee318736a7899ad2405a415," is some sort of data formatting for saving file signatures.

I tried it and it sort of works as advertised ...

From bytestamp, txhash 5e0adc631cab6f9040e125a5eed5c87803c4e95c2e734a1bc3d6c36f56cbb94e has the binary data of a GIF, apparently.


$ .../datacoind getdata 5e0adc631cab6f9040e125a5eed5c87803c4e95c2e734a1bc3d6c36f56cbb94e
TVJdLTBAXy9EV2MxZjRiZGFmY2M4Y2RmMTU0MDIxZjI4NzEyYzNkNjMzLDZmMDNiYjJhNGVlMzE4NzM 2YTc4OTlhZDI0MDVhNDE1LA==


Can't be the GIF, not enough bytes.

The perl source of foo1inge's datacoin-brower will be instructive (when I've understood it's functioning) https://github.com/foo1inge/datacoin-browser/tree/master/perl

Cheers

Graham

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    4032

It'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 :       .
@prefix doacc: .
@prefix rdf:   .
@prefix xml:   .
@prefix xsd:   .
@prefix skos:   .
@prefix rdfs:   .
@prefix dc:     .


: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

be151c377da175c2a06e8d8e103575e27440c9819258a92dc80753d144d93019

but 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

Hi cryptrol,

    Well honestly, the heartbleed bugs only are a problem if you didn't compile your own wallet.
    My node is running OpenSSL v1.0.2l and hence is not affected by heartbleed.

    Who leaves RPC open in the wild anyway without a tcp-wrapper or iptables?

    You bring up a legitimate point and the solution is simply compiling the builds linked to a new version of OpenSSL.

    I'd have figured you were referring to BIP66.

    Much of the "maintenance" can be had by rebasing.
    At that time, new improvements will be inherited and modern binaries may be distributed.

    If anybody is looking for a blockchain to store data; it makes sense to find one which has survived a few years... otherwise what is the point?
    This chain is 1.8G and hasn't been spammed to death and has utility in multiple applications.
    ByteSt@mp is a testament to innovation secured with a chain of blocks.

    If you found Datacoin today and it had a 500G blockchain, would you so easily dismiss it?

    What else did you find aside from an SSL linking problem only affecting those who don't compile their own wallet?

Best Regards,
-Chicago

Hi,

I see movement in DTC, nice!
I still support it by running node 24/7.
I can turn on my old AMD pool for DTC if you guys are interested.
But that will happen in few days, as I'm on holidays right now :-)

No, heartbleed and posterior bugs.
You can restrict RPC to local access but having the bug in there is kinda creepy ...

Hi cryptrol,

    For the OpenSSL bugs are you referring to strict DER signatures?

Best Regards,
-Chicago

Blockchain storage MUST be expensive, very expensive. 159 DTC is actually too cheap IMO.

I don't know what apertus is, but I guess they are using the OP_RETURN size to store data, I fail to see how Datacoin can be leveraged to store this kind of data in front of other (more secure) blockchains.

BTW, as of today, 34Mb of data is stored in the blockchain, besides bytestamp (I don't know what it is), there is nobody really using it.

On the development side, there is a lot of effort to put on it, I don't think any developer will pick the project as it is, too many issues,really old code (still openssl bugs on the main repo), without mentioning the Datacoin own issues with big blocks and network propagation. There is zero incentive for picking this old chain in front of bootstraping a new one, unless you are a hoarder and have millions (literally) of coins.

The chain as it is right now is : unsecure, unreliable, trivially exploitable. Be warned.

Resume:

getdata can be easily replaced with following RPC Calls.

getrawtransaction
decoderawtransaction

The result is a parsed transaction. The data field can be easily extracted from it.

It works for in-wallet and external transactions.

I hope it will be useful.

From bitcoin documentation. https://chainquery.com/bitcoin-api/gettransaction


It seems the GetTransaction function must be correctly replaced with getrawtransaction function.

I have looked at Apertus.io.

Does it use the transaction address as data storage? Is it only 20 bytes per transaction?

It is very essential limitation of Apertus.io.

It seems very ineffective.

DTC is designed for another way.

Apertus.io needs fundamental redesign for effective DTC usage.