watching this thread ...
and graham - there are a few others also ... but im glad you have published this list ...
I stopped recording after 2016-03, there will have been others launched since then but they're relatively easy to fish out with a github search for some masternode-specific code. Cheers Graham |
|
|
|
Along with you I did the same thing. I dumped in the market early to distribute the coins. I kept enough to keep me happy though.
Glad to learn that I wasn't the only one with that understanding, I was playing it by ear. I'm happy enough ... On a different topic: WTS 3+million PNUT  Cheers Graham |
|
|
|
Early, publicly-accessible version of ACME block and tx explorer customised for Slimcoin: http://tessier.bel-epa.com:6053/Be gentle, don't keep hammering “refresh”, block emission interval is 90s. Clicking on the Slimcoin icon+name in the menu bar toggles between mainnet and testnet views. (!!) Block history menu for testnet is incorrect. Search doesn't yet produce results (need to switch to jsonp style). I'm still investigating the appropriate SPARQL strategy for retrieving TX details for the address and inscription details for the inscription listing ... A SPARQL SELECT query is a strange beast: it queries a graph structure but presents the result as a flat table (technically, it's a sequence of sets of variable bindings, but it amounts to the same thing). Duplicates occur because different combinations of values for your variables can be found by basically following different paths in the graph.
...
Another solution is to split your query in two: do a first query that only selects all unique subjects (and possibly all other values for which you know, in advance, that they will be unique given the subject), then iterate over the result and do a separate query to get the other values you're interested in, for each individual subjectID value. This solution may sound like heresy (especially if you're from an SQL background), but it might actually be quicker and easier than trying to do everything in one huge query.
https://stackoverflow.com/a/11441683Much more infrastructure work to be done if ACME is to reach industrial-grade reliablity (failovers, load balancers, backups, etc.). And the services offered could be expanded to include storage and retrieval of metadata pertinent to an inscription (e.g. dc:title, foaf:image). Some minor work TBD on polishing the model, I made an epistemological error that needs correcting and there are too many apparent constants being recorded, we could easily live without them clogging up the graph. Cheers Graham |
|
|
|
So, in September 2015, the $ 100 deposit is now worth $ 2 million? Unbelievable.  Nice profit. Most of the coins were lost or deleted. There is likely five million at most left and many are in masternodes. You can't use the volume on an exchange as an indicator of profit since most of those trades are made by bots. Only in my dreams I've been a supporter since the early days (waves at any old pals still lurking) and for a couple of years had a cron job managing four coins, Chaincoin included, each getting setgenerate for 15 mins per hour. I upgraded to the 0.9 version along with most others but discontinued the quarter-hour duty cycle because the network was clearly receiving adequate hash support for the circumstances. When the across-the-board masternode pump arrived, I had a wallet with 212,000-odd Chaincoin in it and was acutely aware that, given the long back story, there may not have been all that many coins available. So, over the day, I fed nearly 200,000 CHC into the market, making a handful of BTC. Ofc, matching that sale against today's price will have everyone giggling. But I have a sneaking feeling that had I simply parked my arse on my stash and waited for $6, I'd still be waiting today. As the man said “I made my money by selling too early”. I'm delighted that Chaincoin has gained some hard-won long-term support. I've kept 10000 CHC as a souvenir (the server-hosted node is a master node, ofc) and have gladly routed some my ill-gotten gains to provide some relief to a close family member labouring under debt stress. At the time, I knew I was selling too early (and too cheaply if the pump proved successful at raising the floor price) but the market needed my support, I felt. So there you go. Cheers Graham |
|
|
|
Once ACME is finished, would this dataset be publicly accessible in a machine-readable way so the data can be included in a web site or for a simple web2web instance that grabs the data via JavaScript?
Fuseki offers a range of services including a standard SPARQL endpoint on # http;//localhost:3030/{dataset}/sparql?query={query} change localhost to remote host (value as advised privately) - try it from home ... import json
import requests
query = "http://localhost:3030/slmchain/sparql?query=PREFIX+ccy%3A+%3Chttp%3A%2F%2Fpurl.org%2Fnet%2Fbel-epa%2Fccy%23%3E%0Aselect++(SUM(%3Fvalue)+as+%3Ftotal_slm_burned)+WHERE%0A%7B+%3Ftxo+ccy%3Aaddress+ccy%3ASfSLMCoinMainNetworkBurnAddr1DeTK5+.%0A++%3Ftxo+ccy%3Avalue+%3Fvalue%0A%7D"
netburnedcoins = json.loads(requests.get(query).content.decode('utf-8'))['results']['bindings'][0]['total_slm_burned']['value']
I'll scout around for an appropriate javascript library. Fuseki also allows the entire graph to be requested, so it's completely copyable. Cheers Graham |
|
|
|
In terms of branding, one thing we might consider is referring the coin simply as "Slim" instead of always "Slimcoin." Increasingly coins are known by their first name since everyone knows these are coins. For example, people refer to Dash, not Dashcoin.
I love how it rolls of the tongue.
"How much?"
"49 Slim."
Slim is the best-ever coin name for commerce, because it makes prices sound smaller.
I've noted that tendency (in) myself. It does seem an easy and natural contraction (at least for native EL speakers) perhaps because its consonance works both acoustically and semantically. The move from Darkcoin to Dash perhaps should have prompted people to think a bit more deeply about the nuances of the ways and means of externalising group values to provide a more communicative signal of the collective ethos. But then again, this is bitcointalk, the largest “mixed ability” class on the planet. The date-based organisation of Bitcointalk BBS threads is ill-suited to the painting of a coherent large-scale picture. Scene-setting posts rapidly become effectively inaccessible, almost to the point of negating the effort it took to construct them in the first place. Part of my motivation to update Slimcoin to enable OP_RETURN txs was in order to be able to collate some of my more effortful posts. In the interim, I edited my web2web publication “A different perspective on cryptocurrency” to allow the use of cdn-hosted resources and saved the result to: https://minkiz.co/library/a-different-perspective-on-cryptocurrency.htmlIt's standalone, apart from the cdn-delivered JQuery and Semantic-UI javascript+css resources (and, if i wanted to be tediously scrupulous, I could always include them as yuuuge base64-encoded strings.) Cheers Graham |
|
|
|
Do you have any resources where I can get my head sucked into regarding RDF?
Here's a PDF of my write-up of the preliminary R&D scratchpad work which goes into a bit more detail of the RDF modelling as applied to an altcoin's blockchain (V, in this instance): https://minkiz.co/library/signed-graphs.pdf in which I use the ActivityStreams examples to illustrate the principles of publishing via the inscription of RDF graph signatures on the blockchain. The W3C has a set of ActivityStreams Examples in JSON-LD (RDF expressed as JSON). The examples are not dissimilar to the JSON output from an altcoin RPC API and should give you an idea of what's involved in publishing JSON-LD (*cough* RDF). The overall concept is the W3C's ActivityPub effort, which is basically speccing out a set of standardised APIs for social networking. Nice of them to have prepared the ground so thoroughly, we can ”just” pick up the API spec and implement it for ourselves. As regards compute resources, the server is a 25-euro a month Hetzner “robot”, 16Gb RAM, 8 threads (getting fairly elderly, now). The file of ntriples ran to 7.8Gb, iirc, haven't checked how much HD space is being used by TDB (the Jena persistent store back end). ACME needs the entire graph but you can just trim it down to the last X blocks and tx if you know that's where your queries are vectored. I am running the Slimcoin testnet graphchain on my 8 year-old laptop. On the server I set Fuseki's JVM envars to: # JVM_ARGS=${JVM_ARGS:--Xmx1200M}
JVM_ARGS=${JVM_ARGS:--Xmx2048M}
JVM_ARGS=${JVM_ARGS:--Xms2048M}
JVM_ARGS=${JVM_ARGS:--XX:NewSize=512M}
JVM_ARGS=${JVM_ARGS:--XX:MaxDirectMemorySize=256M}
There'll be sage advice on tuning from the Fuseki mailing list I imagine. RDF ain’t so bad once you can see it actually applied to something you can relate to. It’s basically a highly sophisticated and well-thought out database representation. Each statement is a standalone piece of data: the row index, the column index and the cell content, the latter being either a literal or a row index. Namespaces are used to segregate collections of row and column indices. In a classic example of elegant re-use, namespaces are URIs and indices are #fragments. The most popular format hangs the column indices off've the row index: row_index_id:
column_1 cellval
column_2 cellval
...
and it is reasonably transparently instantiated as:
http://purl.org/net/bel-epa/ccy#SfSLMCoinMainNetworkBurnAddr1DeTK5
http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://purl.org/net/bel-epa/ccy#Address ;A shorthand form of the URL#fragment is available: PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
ccy:SfSLMCoinMainNetworkBurnAddr1DeTK5 rdf:type ccy:Address ;
ccy:C00000766be5a4bb74c040b85a98d2ba2b433c5f4c673912b3331ea6f18d61bea rdf:type ccy:Block ;
ccy:height 0^^xsd:integer ;
ccy:size 313^^xsd:integer;
ccy:version 1^^xsd:integer
ccy:merkleroot ccy:Cbae3867d5e5d35c321adaf9610b9e4147a855f9ad319fdcf70913083d783753f ;
ccy:time "2014-05-08 19:47:40 UTC"^^xsd:dateTime ;
ccy:nonce 116872^^xsd:integer
ccy:bits "1e0fffff"^^xsd:hexaDecimal ;
ccy:flags "proof-of-burn"@en
ccy:difficulty 0.00024414^^xsd:decimal ;
ccy:nextblockhash ccy:C000006e022fc5e432e55cd61885d6ab9bb2ad6d5cef943f0e397ee21fe37b5db ;
...
The above counts as a populated graph - it has at least one statement. In the world of RDF you can simply add one graph to another. It makes sense if you think of it as adding one standalone collection of unordered row/col/cell triples to another standalone collection of unordered subj/pred/obj triples and ending up with one large standalone collection of unordered triples. Column indices can (preferably) resolve to a formal description, an ontology (see CCY for the ontology used to model the blockchain. Also expressed in RDF:
ccy:height a owl:ObjectProperty ;
dc:description "The sequence of the block in the current blockchain."@en ;
rdfs:domain ccy:Block ;
rdfs:isDefinedBy <http://purl.org/net/bel-epa/ccy#> ;
rdfs:range xsd:integer ;
ns:term_status "unstable" ;
skos:prefLabel "height"@en .
(height is an integer and a property of Block) Useful terms are freely borrowed from other namespaces to avoid NIH and a quick dekko at Richard Cyganiak’s 100 most popular RDF namespaces gives a hint of the range of subject ontologies available. Conventionally, row_index, column_index, cell_value dissolves into subject, predicate, object, a more natural expression. Modelling the blockchain is easy, hashes (e.g. previousblockhash, merkleroothash, nextblockhash) are row indices (subject) and are written as ccy:C<hash>, addresses (in WIF format) are also row indices (subject) and are written as ccy:<wifaddress>, all attributes (predicate) are written as ccy:<attribute> and everything else (object) is a literal. Querying the graph is straightforward with the SPARQL query algebra and by algebra I mean ?x AND ?y, i.e. logic operators and variable bindings. In SPARQL, for convenience, AND is written as a full stop, conventionally at the end of line.
PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>
select (SUM(?value) as ?total_slm_burned) WHERE
{ ?txo ccy:address ccy:SfSLMCoinMainNetworkBurnAddr1DeTK5 .
?txo ccy:value ?value
}Once you've got your queries worked out, you can use them with sgvizler to create charts.
PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>
select (SUM(?value) as ?total_slm_burned) (COUNT(DISTINCT ?txo) as ?num_burn_txs) WHERE
{ ?txo ccy:address ccy:SfSLMCoinMainNetworkBurnAddr1DeTK5 .
?txo ccy:value ?value .
?tx ccy:output ?txo .
?tx ccy:time ?datetime .
FILTER(?datetime < 1430434800 && ?datetime > 1427842800)
}"3284.6929"^^xsd:decimal "24"^^xsd:integer(2015-04-01T00:00:00Z to 2015-05-01T00:00:00Z) Feel the power... https://github.com/mgskjaeveland/sgvizlerCheers Graham |
|
|
|
That's good. What I want to do with this feature are mainly two things:
- follow the "burn address" to track "total burnt coins" & "available coin supply"
- follow Slimcoin addresses to track inscriptions
Taking a moment to randomly follow-up because I'm in the vicinity ... in order of appearance: PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>
select (SUM(?value) as ?total_slm_burned) (COUNT(DISTINCT ?txo) as ?num_txs) WHERE {
?txo ccy:address ccy:SfSLMCoinMainNetworkBurnAddr1DeTK5 .
?txo ccy:value ?value
}
The above is net total burned, i.e. total-number-of-coins-sent-to-unspendable-address. PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>
SELECT DISTINCT ?tx ?bhash ?datestamp ?asm WHERE {
?txo ccy:address ccy:SlimcoinAddressToBeFollowed .
?txo ccy:pkasm ?asm .
?tx ccy:output ?txo .
?tx ccy:blockhash ?bhash .
?tx ccy:time ?datestamp
FILTER regex(?asm, "OP_RETURN")
} ORDER BY DESC(?datestamp) LIMIT 50
Will list, in date order, the last 50 inscriptions: transaction hash, block hash, datestamp and scriptSig contents containing the inscription) for the followed address. Cheers Graham |
|
|
|
Anyway, I believe I made my case. Now it's up to the devs and community to decide.
I had hoped to help you avoid this exact situation but I guess I wasn't sufficiently explicit ... what do you expect to happen?Cheers Graham |
|
|
|
I can make what I believe is a cogent argument that the existing logo has earned its keep in that it's been hanging in the window for all Slimcoin users thus far and therefore has provided a common visual identity that all club members are familiar with.
I'm sorry to say but it hasn't. So? When a client approaches you to create a new brand identity for their product, service or event, things can seem a little bit daunting. But don’t worry - all you need to do is apply all the skills you’ve built up in your design career in a slightly different way. To help you along, here are some expert tips on developing the perfect brand identity that will make both you and your client happy.
Who knows, come next year it might be your brand on the corner of every street...
1. Strategise from the start
Before starting work on a new brand identity, draw up a brand strategy to form a set of values and a proposition upon which the client and you agree. If this doesn’t happen at the start of a project, the client will have no benchmark against which to gauge whether the creative concepts are relevant.
2. Work with a brief
If design concepts are created without thorough briefing on the brand, then both creative and client end up relying too much on an intuitive idea of the solution, and accordingly run the risk of feedback being subjective. A brief that’s drawn up from a clear brand strategy enables both parties to rationalise the design decisions.
3. Do your research
Understand the personality of the brand - its history, function and the ethos behind it all. Extract every nuance of who the client is and what the company’s about, including the intended target market, how it wishes to be perceived, and formats and outlets for where it wishes to promote itself.
4. Gauge their expectations
It can be a valuable exercise to ask clients to do their own exploration into finding references for their branding: you’ll soon see what they like, and - usefully - how broad their understanding of design is.
5. Check the competition
Look at the colours, typefaces and visual styles used by rivals, and then create something truly unique, positioned away from them all. Think of the varied uses, colours and sizes of your design. Then stand back and consider it with your client hat on.
6. Don’t rely on the logo
While a logo is sometimes the linchpin that holds a brand identity together and makes it instantly recognisable, brands aren’t built on logos alone. When creating a brand identity, don’t focus on the separate elements. make sure you always consider the bigger picture and how all the smaller elements interact with one another.
7. Don’t ignore the client
No matter how much experience you have, the client knows the product better than you ever will. Rushing in with a set of *en vogue* visuals might get you praise from your peers, but could be off-kilter with your client’s expectations and what’s best for the brand.
8. Exercise restraint
Understanding the client’s needs is the first step to creating a great brand identity. By limiting colour palettes, details and typography, a simple identity can become timeless and move alongside the client’s ever-changing visual landscape.
9. Spot what’s special
If that ‘something special’ about the product or client isn’t identified at the beginning, you’ll be missing a massive opportunity to connect with the people you’re creating the brand for, and the audience it must attract. Get this bit right and you’re already halfway there; get it wrong and you’ll end up with little to spur your imagination on.
( http://www.creativebloq.com/branding/create-brand-identity-1233282) Cheers Graham Edit: addressed omission of origin |
|
|
|
gives error during configure ./configure: line 12234: SECP_64BIT_ASM_CHECK: command not found
./configure: line 12263: SECP_INT128_CHECK: command not found
./configure: line 12291: SECP_INT128_CHECK: command not found
./configure: line 12316: SECP_GMP_CHECK: command not found
./configure: line 12422: SECP_OPENSSL_CHECK: command not found The messages suggests that autoconf isn't finding the relevant m4 macros which suggests there's a missing file or an existing file has missing stanzas. Cross-referencing the m4 contents with those of a successfully-compiling coin of similar vintage and configuration might help you fill in the missing bits. Cheers Graham |
|
|
|
Does ACME also allow to follow the balance of an address? I have tried that with the FugueCoin explorer on minkiz.co, but if I click on an address there I get an "Internal Server Error".
I remember you said that was the most difficult feature for a block explorer. But if the whole blockchain is represented in RDF, would that mean a SPARQL query would make it possible?
The RPC-API leaves a *lot* to be desired when it comes to transactions and it is this lacuna that generally impels the implementors of block & tx explorers to create and maintain a database which can be readily searched (hence the anatomy lesson, it impacts the db structure). In short, yes, it should. And if it doesn't, that means the model is deficient and I can re-jig it to work. Of course, the *real* firework display is yet to begin. ...
Whew. Isn't that what Tauchain wanted to achieve - in short, we're now a competitor for Ethereum?  Not really. ohad's approach replaces the whole shebang with an RDF model and some consensus mechanism that I didn't grok plus some added temporal logic supposedly to implement automatic contracts. I'm not interested in attempting a solo rewrite of Bitcoin, instead I prefer to leave the client as is and to view the blockchain mechanism as providing indexed clock ticks demarking successive states of the RDF model, more along the lines of chainpoint than tau. As for “automatic contracts”, if people insist on fully exploring the intricate delights of the symbol grounding problem, I shan't stand in the way. My background in epistemology has taught me to prefer a simple model that is well-structured to support the typical operations in the domain of discourse. The fact that such an approach makes life easier for the reasoning engines is not unrelated. I'd much rather have access to both open source and proprietary reasoners, e.g. FACT++ and Stardog respectively. Working with RDF graphs is rather a different ballgame. At the moment each new block results in at least 30 triples added to the graph, more for each additional tx in the block. We have around a million blocks which gives us around 40 million triples in the graph. A glimpse into the principles ( https://github.com/stardog-union/stardog-docs/wiki/Reasoning-chapter-(Stardog-2.0)): OWL 2 Profiles
As explained in the OWL 2 Web Ontology Language Profiles Specification of the W3C, an OWL 2 profile is a trimmed down version of OWL 2 that trades some expressive power for the efficiency of reasoning. There are three OWL 2 profiles, each of which achieves efficiency differently.
OWL 2 QL is aimed at applications that use very large volumes of instance data, and where query answering is the most important reasoning task. The expressive power of the profile is necessarily limited, however it includes most of the main features of conceptual models such as UML class diagrams and ER diagrams.
OWL 2 EL is particularly useful in applications employing ontologies that contain very large numbers of properties and/or classes. This profile captures the expressive power used by many such ontologies and is a subset of OWL 2 for which the basic reasoning problems can be performed in time that is polynomial with respect to the size of the ontology.
OWL 2 RL is aimed at applications that require scalable reasoning without sacrificing too much expressive power. It is designed to accommodate OWL 2 applications that can trade the full expressivity of the language for efficiency, as well as RDF(S) applications that need some added expressivity.
Each profile restricts the kinds of axiom and assertion that can be used in a DB. Intuitively, QL is the least expressive of the profiles, followed by RL and EL; however, strictly speaking, no profile is more expressive than any other as they provide incomparable sets of constructs.
Stardog supports the three profiles of OWL 2 by making use of Blackout and Pellet. Notably, since TBox BGPs are handled completely by Pellet, Stardog supports reasoning for the whole of OWL 2 for queries containing TBox BGPs only.
I have to say that I've yet to encounter a usefully expressive temporal FOL and the last time I looked at temporal second order logic, (McDermott, IIRC) he was reporting that it collapsed into monotonic S5. Yeah, okay temporal logic was the subject of my Masters thesis, so it was a while ago but some problems are seriously deep. So no, not a competitor to Ethereum but yes - in principle, I suppose, but without a $30 million ICO who's gonna take it seriously? I should point out that I'll be releasing as open source the blocknotify Python script that generates and maintains the graph (it's a tad scrappy atm and a little too déshabillé for public exposure) and ditto for ACME-slimcoin so *any* altcoin that supports OP_RETURN can have the same RDF-based inscription and publishing facilities, if the node owners can recruit adequate technical resources. It's not much more than a logical development from publishing a torrent magnet - the resource referenced by my blockchain inscription is out there on the torrent network but requires a torrent server. Sourcing my own torrent server would give me robustness, assuming the ISP is tolerant of torrent servers but should *everyone* need to run their own torrent server? ... but parking one in the guts of the coin would likely end in tears where Slimcoin is concerned... and.. and.. the more I thought about it, the more it became clear that this was a potentially a community service provided by volunteer members and probably would run just like our local dinghy sailing club - they are obliged to provide “safety boat” cover - a RIB staffed by club members whose duty that day is to speed around, throwing up great washes of spray and, co-incidentally, attend any capsizes and ensure that sailing members are safe. There's an informal team that shoulders the extra load of dealing with the RIBs, trailering them here'n'there, basic maintenance, running training courses etc. Their contribution is respected by all. Respect from peers is something that cannot be purchased, only earned. As regards the proposed logo redesign - it will stand and fall on its merits in the eyes of the club members. I welcome the engagement and I do respect the enthusiasm but from the perspective of a graphic designer I have to confess that I don't see how trading off've a (to be blunt) shadowcoin swastika copy logo serves to visually communicate the shared values of the club members and suspect that it isn't likely to unless the exercise is adequately informed by a well-written creative brief ( http://beloved-brands.com/2012/05/28/creative-brief/). I'd start the creative brief by examining what role the logo is currently playing and how that works for people. I can make what I believe is a cogent argument that the existing logo has earned its keep in that it's been hanging in the window for all Slimcoin users thus far and therefore has provided a common visual identity that all club members are familiar with. Slimcoin is a more technically demanding coin than most and I see the slightly more formal serif font as consonant with the technical zeitgeist (sloppy is bad), plus (less convincingly) the fact that it is also a trading symbol is technically an asset. Its simplicity lends it some visual distinctiveness amongst the rash of S-themed altcoin logos, check for yourself: https://minkiz.co/coin/I note that a vote was proposed, I'm militantly against fake representation. I vigorously encourage people to first read upthread, they may save themselves some thrashing around. Slimcoin is a peer-to-peer networked cryptocurrency; voting is pointless and irrelevant as the result cannot be enforced. There is no “official” logo, there is no “official”anything. The only thing that counts in a peer-to-peer network is the implicit social consensus that binds all Slimcoin users into accepting the simple cryptographic rules that define and constrain the playing field, i.e. a network of token-exchanging peers --- which basically boils down to “whatever the club members collectively decide to do, in the event”. Cheers Graham |
|
|
|
I have covered the PoS resource usage problem on the slimco.in website in the Proof of Stake guide. (Graham, correct me if there's something wrong) Nothing wrong that I can see, looks good. Maybe an idea to include a reference to AizenSou’s post on the old thread: https://bitcointalk.org/index.php?topic=613213.msg7716530#msg7716530 Fwiw, amongst other things, I'm working my way through all 250-odd pp of the old thread with an aim of collating the technical comments into a coherent whole. On another matter, I'm pleased to report a significant amount of progress (admittedly the result of a significant amount of effort). The Slimcoin-specific version of ACME is close to achieving deployment status, it now displays all Slimcoin tx (inc the genesis transaction) and inscriptions: spin-off material: a PR for the website: the anatomy of the Slimcoin genesis block
Front page 
Latest transactions 
Geoip-location map of countries hosting Slimcoin nodes (canned, from copy'n'pasta of server-hosted client's response) 
And the one that took up most of the effort ... a list of inscriptions on mainnet:  Those following along closely at home will note the inclusion of the SPARQL raw response and draw their conclusions accordingly - the blockchain has been mapped into RDF ( Apache Jena + Fuseki) and is available for the resolution of SPARQL queries. I have a blocknotify script in Python that updates the RDF graph with freshly-minted blocks+tx as they occur. Initially, I ran it in “catchup” mode, dumped the blockchain as ntriples and read it into Jena's TDB using the command-line utility. Fuseki has happily been hosting the Slimcoin RDF blockchain for a week or so and I've been firing assorted SPARQL queries at it --- it's doing okay thus far. Of course, the *real* firework display is yet to begin. Now that we have an RDF model of the blockchain, inscriptions can be signature hashes of RDF graphs. This means that you will be able to inscribe the signature of an arbitrary RDF graph and the metadata contained in the graph can be retrieved and used to decorate/accompany the inscription with appropriate metadata content such as the title, author, date, price, thumbnail, snippet, contract id, actually *anything* that you can express in RDF, which is pretty much anything at all. Cheers Graham |
|
|
|
Why would they?
The general experience is that without an appropriate account management scheme, a steady stream of stake txs inevitably translates into an ever-increasing demand on the CPU as the client thrashes through the accumulated stake txs, calculating each one's contribution to the overall stake weight. (Forensic archaeology informs me that subscribers to the original Slimcoin thread had worked this out for themselves but the lesson had gotten somewhat lost in the mists of time.) The Sprouts codebase is very close to Slimcoin's and several Sprouts users were reporting client issues with excessive CPU usage and the Windows client crashing at frequent intervals, identical to those experienced by some Slimcoin client operators. The exchange reported that the Sprouts wallet crashed every few minutes, a severity apparently not experienced by any other operator of the Sprouts client. Whilst it is possible the exchange were experiencing some totally unrelated problem that was uniquely specific to their set-up, one would expect them to be motivated to solve their specific issue rather than bail out by de-listing the coin. But, as the man said: “It’s 2017 and nothing makes sense any more”. IMO it's a reasonable conjecture that exchanges which configure their Sprouts or Slimcoin client to earn mint-by-proof-of-stake rewards on client deposits are likely to experience this problem to a significant degree unless the stake calculation CPU demand is adequately supported with additional compute resources. (That's my understanding at least. Happy to be corrected) Cheers Graham |
|
|
|
Dept of Work-in-Progress ... few (if any) 3rd-party “blockchain” apps .. can reasonably be expected to work with Slimcoin unless they are extensively refactored ...
Such as this version of ACME that has been specialised for the Slimcoin block structure and JSON responses: Block listing(Configurable list length trimmed from std 32 down to just 4 for demo) Key: red flame: mint-by-proof-of-burn blue laptop: mint-by-proof-of-stake green desktop: mint-by-proof-of-work  Block detail:The “unprocessed JSON response” is an accordion drop-down that reveals the (surprise!) unprocessed JSON response.  Transaction detail (in progress)  It works, now I'm trying to get it to work as expected. No commits yet, the end result will be a VM+Ansible playbook combo that is as close to a “click’n’drool” solution as I can arrange, provisioning a VM with the support software to compile and deploy a Slimcoin node and the ACME Slimcoin block explorer. Cheers Graham |
|
|
|
Dept of Mining: My opinion was sought as to whether the Python-implemented p2pool could be made to work with Slimcoin, upon inspection it proved not immediately possible. It's reasonably easy to supply the main parameters and run the app but (as far as I can ascertain) the Slimcoin API's JSON responses cause something somewhere in twisted’s async innards to choke. Co-incidentally I was also making a quick pass over some other third-party apps: the Abe, insight and iquidus block explorers. I managed to find a Javascript implementation of the dcrypt PoW algo but again, it seems that Slimcoin's RPC-API JSON responses aren't what the apps are expecting nor is the block structure the same and they all choke deep down inside, f'rinstance one of the supporting Angular JS libs underpinning the iquidus explorer can't even successfully parse the JSON emitted by Slimcoin. To give an idea of how far away from a solution we are, the Slimcoin codebase is still primarily based on the 2012 Bitcoin 0.6.3 version and still uses version 1 blocks as evidenced in the code. Bitcoin upgraded to version 2 blocks in Feb 2013. I collected a few scrappy notes: May 23 2012 - 0.6.3 - https://github.com/bitcoin/bitcoin/blob/6e0c5e3778b83f128f6f14c311d5728392053581/src/main.hCBlock()
{
SetNull();
}
IMPLEMENT_SERIALIZE
(
READWRITE(this->nVersion);
nVersion = this->nVersion;
READWRITE(hashPrevBlock);
READWRITE(hashMerkleRoot);
READWRITE(nTime);
READWRITE(nBits);
READWRITE(nNonce);
// ConnectBlock depends on vtx being last so it can calculate offset
if (!(nType & (SER_GETHASH|SER_BLOCKHEADERONLY)))
READWRITE(vtx);
else if (fRead)
const_cast<CBlock*>(this)->vtx.clear();
)
void SetNull()
{
nVersion = 1;
hashPrevBlock = 0;
hashMerkleRoot = 0;
nTime = 0;
nBits = 0;
nNonce = 0;
vtx.clear();
vMerkleTree.clear();
nDoS = 0;
}BTW, Slimcoin's version of the above is: CBlock()
{
SetNull();
}
IMPLEMENT_SERIALIZE
(
READWRITE(this->nVersion);
nVersion = this->nVersion;
READWRITE(hashPrevBlock);
READWRITE(hashMerkleRoot);
READWRITE(nTime);
READWRITE(nBits);
READWRITE(nNonce);
//PoB data
READWRITE(fProofOfBurn);
READWRITE(hashBurnBlock);
READWRITE(burnHash);
READWRITE(burnBlkHeight);
READWRITE(burnCTx);
READWRITE(burnCTxOut);
READWRITE(nEffectiveBurnCoins);
READWRITE(nBurnBits);
// ConnectBlock depends on vtx following header to generate CDiskTxPos
if (!(nType & (SER_GETHASH|SER_BLOCKHEADERONLY)))
{
READWRITE(vtx);
READWRITE(vchBlockSig);
}
else if (fRead)
{
const_cast<CBlock*>(this)->vtx.clear();
const_cast<CBlock*>(this)->vchBlockSig.clear();
}
)
void SetNull()
{
nVersion = 1;
hashPrevBlock = 0;
hashMerkleRoot = 0;
nTime = 0;
nBits = 0;
nNonce = 0;
//proof-of-burn defaults
fProofOfBurn = false;
hashBurnBlock = 0;
burnHash = 0;
burnBlkHeight = burnCTx = burnCTxOut = -1; //set indexes to negative
nEffectiveBurnCoins = 0;
nBurnBits = 0;
vtx.clear();
vchBlockSig.clear();
vMerkleTree.clear();
nDoS = 0;
}
Moving on --- Feb 5 2013 - 0.8.0: https://github.com/bitcoin/bitcoin/blob/d38c6488d067c2e88726e2ca99bc76fd67dab49bclass CBlockHeader
{
public:
// header
static const int CURRENT_VERSION=2;
int nVersion;
uint256 hashPrevBlock;
uint256 hashMerkleRoot;
unsigned int nTime;
unsigned int nBits;
unsigned int nNonce;
CBlockHeader()
{
SetNull();
}
IMPLEMENT_SERIALIZE
(
READWRITE(this->nVersion);
nVersion = this->nVersion;
READWRITE(hashPrevBlock);
READWRITE(hashMerkleRoot);
READWRITE(nTime);
READWRITE(nBits);
READWRITE(nNonce);
)Moving on yet further --- Sep 23 2014 - 0.9.3 https://github.com/bitcoin/bitcoin/blob/40d20412ff173e8eea2f456fd749663c8cabda18/src/main.cpp// Reject block.nVersion=1 blocks when 95% (75% on testnet) of the network has upgraded:
if (block.nVersion < 2)So I guess that, with the difference in Simcoin's block structure, its use of version 1 blocks and the difference in its JSON responses, there are few (if any) 3rd-party “blockchain” apps written after 2013 that can reasonably be expected to work with Slimcoin unless they are extensively refactored to handle those differences. Cheers Graham |
|
|
|
From the “One VCN will always equal 1 VCN” Dept: Bitcoins to come under anti-money laundering reporting requirements
A new bill was introduced in the US Senate. The Bill's Section 13 aims that people report digital and cryptocurrencies in excess of $10K entering the US.
https://anonymster.com/bitcoins-anti-money-laundering-reporting/https://www.law.cornell.edu/uscode/text/31/5312 <- The “United States Code” referenced below https://www.congress.gov/bill/115th-congress/senate-bill/1241/text#toc-idea0e9489fc8f46379f95bb56c8bbbda5SEC. 13. PREPAID ACCESS DEVICES, DIGITAL CURRENCIES, OR OTHER SIMILAR INSTRUMENTS.
(a) In General.—Section 5312(a) of title 31, United States Code, is amended
...
(2) “financial institution” means
...
(K) an issuer, redeemer, or cashier of travelers’ checks, checks, money orders, prepaid access devices, digital currency, or similar instruments, or any digital exchanger or tumbler of digital currency
...
(3) “monetary instruments” means—
(B) as the Secretary may prescribe by regulation, coins and currency of a foreign country, travelers’ checks, bearer negotiable instruments, bearer investment securities, bearer securities, stock on which title is passed on delivery, prepaid access devices and similar material;
...
(7) ‘prepaid access device’ means an electronic device or vehicle, such as a card, plate, code, number, electronic serial number, mobile identification number, personal identification number, or other instrument, that provides a portal to funds or the value of funds that have been paid in advance and can be retrievable and transferable at some point in the future.
...
(c) Customs And Border Protection Strategy For Prepaid Access Devices.—Not later than 18 months after the date of enactment of this Act, the Secretary of Homeland Security, in consultation with the Commissioner of U.S. Customs and Border Protection, shall submit to Congress a report—
(1) detailing a strategy to interdict and detect prepaid access devices, digital currencies, or other similar instruments, at border crossings and other ports of entry for the United States
A classic example of the incoherent ravings and random spasmodic jerks that are characteristic of a corrupt hierarchy in the process of collapse. Cheers Graham |
|
|
|
It's XCP if I remember correctly.
https://counterparty.io/platform: XCP was created by “burning” bitcoins, which involved sending coins to an unspendable address in exchange for XCP, ensuring an even and fair distribution of the currency. In January 2014, over 2,100 bitcoins were burned, creating about 2.6 million XCP
Cheers Graham |
|
|
|
... but Nova seems has no problem?
They've recently been experiencing some general difficulties but afaict nothing specific to the Slimcoin client. Cheers Graham |
|
|
|
|
Show Posts
