@muf18: Maybe ask Coinhouse to provide a full "getinfo" string (result of command "getinfo" in the Console or "slimcoind getinfo" when using the command line/daemon) so we can see if they are 1) on a wrong block height (e.g. on a fork, or stuck) and 2) if they are using a recent version or an outdated one.
It would also be interesting to know the deposit address where you sent the Slimcoins, so we can see if they sent the SLM to another wallet or if they're "stuck" there. Normally exchanges, once coins are deposited, transfer the coins to their main hot & cold wallets, so if they're still on the deposit address then there's probably something wrong with their system.
PS:
I spotted something I believe a slight inconsistency in the RDF graph of the blockchain (in the ontology the inconsistency seems to not exist):
When I query the "proofhash" of a block, I get a simple string/hexBinary with the hash. But if I query the "blockhash" of a transaction, I get an incomplete URI of the block object itself.
e.g. for block 1 in a text file containing the beginning of the SLM blockchain:
:proofhash "000006e022fc5e432e55cd61885d6ab9bb2ad6d5cef943f0e397ee21fe37b5db"^^xsd:hexBinary ;
while if I look at the transaction 9f18572d7c68a866a487d93669856a060d64a08f689bf032fa66bcba442f7c8b, included in that same block, I get:
:C9f18572d7c68a866a487d93669856a060d64a08f689bf032fa66bcba442f7c8b
a :Transaction ;
:blockhash ;
the hash being correct, but the format different. The format, unfortunately, is also different from the block RDF node URI itself.
Is this a bug to be fixed (it makes CONSTRUCT queries more difficult) or does it have a deeper meaning?
http://purl.org/net/bel-epa/ccy#blockhash (and #proofhash too) says that the range is a simple "string", that would be an indication for it to be a bug ...
Thanks
PS2: The line in blocknotifybase.py that adds blockhash seems to be:
for txk, dt in txkeys.items():
if txk in ['blockhash']:
self.g.add((txnode, CCY[txk], URIRef(ccy_urif.format(tx.get(txk)))))
Edit 3: I don't see nothing strange in this part of the code, as the CCY URI prefix seems to be added here; but the result of a SPARQL query is still different (the "blockhash" value is different to the format of the block as a subject).
An example to show what I mean: When I query this:
PREFIX ccy:
SELECT ?tx ?block ?b
WHERE {
?block ccy:height 1 .
?tx ccy:time 1401311603 .
OPTIONAL { ?tx ccy:blockhash ?b . }
}
I get this result:
{
"head": {
"vars": [ "tx" , "block" , "b" ]
} ,
"results": {
"bindings": [
{
"tx": { "type": "uri" , "value": "http://purl.org/net/bel-epa/ccy#C9f18572d7c68a866a487d93669856a060d64a08f689bf032fa66bcba442f7c8b" } ,
"block": { "type": "uri" , "value": "http://purl.org/net/bel-epa/ccy#C000006e022fc5e432e55cd61885d6ab9bb2ad6d5cef943f0e397ee21fe37b5db" } ,
"b": { "type": "uri" , "value": "C000006e022fc5e432e55cd61885d6ab9bb2ad6d5cef943f0e397ee21fe37b5db" }
}
]
}
}
being "b" a value for the blockhash property, but in a different format than "block".
as I could have used RDFLib methods for that distinction ... I'll see if the distinction makes sense or not.