Slimcoin | First Proof of Burn currency | Decentralized Web

[gjhiggins]

Btw. they have written me again 0.1BTC, even tho they should charge me.
I don't really understand this.

Neither do I, what you've written is opaque. Could you re-transmit?

Btw. 2 - can someone merge addnodes, from this into master branch ?
https://justpaste.it/1bcq1

They said that nodes should be included in source code.

As expressed, that doesn't make sense to me. What would be the point of that particular piece of pantomime? Yobit can do this for themselves when they compile the client. Do you have a pointer to where these requirements are detailed? I appreciate the motivation behind the pasted list but without any kind of provenance, I don't see what relevance it can have in a cryptocurrency context - particularly when the Slimcoin client offers a getpeerinfo RPC command which provides the required information.

In case this basic point has slipped anyone's attention, absolutely anyone is free to edit the source code

... to include either an updated/expanded strDNSSeed binding or an expanded pnseed binding, or both

... and either just simply run it for themselves or public-spiritedly submit a PR to the slimcoin-project repos - or indeed set up their own repository to offer an alternative reference client.

All that would remain to be done is for someone to invent and implement a mechanism which will then impose this change on all Slimcoin users, including the half-dozen or so apparently very satisfied users of Slimcoin 0.3 who see no reason to change anything, thank you very much

Which is why it is an obvious piece of pantomime, all show and no substance.

While we're on the subject, Slimcoin was launched with just one strDNSSeed binding (dnsseed.slimcoinpool.com), augmented later with dnsseed.furiousnomad.com and dnsseed.shitcoinrapist.club¹, none of which were resolvable by Nov '16 so I removed them entirely.

I replaced them with a(n also unresolving) Namecoin placeholder: seed.slimcoin.bit, ready for when someone volunteers to commit to funding a stable DNSSeed seed node/domain address or set up and maintain a reliable Slimcoin dnsseeder.

Cheers

Graham

¹ A sad testament to the immaturity of the developer's judgement - if you're anything like me, you'll find yourself asking “Jeez, if he's screwed up such a no-brainer, what else has he screwed up that I haven't yet spotted?”

[muf18]

Sorry, I was a little stressed, because I have definately screw up.

There was creation of new code and then you could also, activate it on the same page. I didn't activate, and request (with not activated code), when through, so I thought it's all ok.

Now today I activated, and made second request. I don't know, if it's right, or not, because yobit gives me a vibes of shady exchange.

And now I have my 0.1BTC also on my account on yobit, even tho they should charge me for it. Strange...

dns shitcoinrapist? OMG, original dev definately was immature, and odd...

[gjhiggins]

On another topic, I have had another issue with running the code on Arch Linux. Boost was recently updated to version 1.66.0, and I have the following error when compiling:

[...]

This appears to be somewhat similar to this (same boost version): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224131

I have had a bit of a look but cannot see any solutions. Has anyone else got any suggestions of where to look or what to do?

The code in bitcoinrpc.cpp uses some boost asio/ssl calls that were deprecated in boost 1.48 and which are going to kick in as compilation errors sooner or later unless the version is pinned or code added to enable a version compability switch.

Although there aren't any specific examples for me to use as a model, the boost documentation is clear enough to work with in terms of making explicit the new “idiom” and the code comment links to the relevant boost version documentation pages ...

https://github.com/slimcoin-project/Slimcoin/commit/bb6c7a3ce5fb4e0b714fee72ce87b0ebd74aa136

Cheers

Graham

[gjhiggins]

dns shitcoinrapist? OMG, original dev definately was immature, and odd...

Not orig dev, was included in subsequent development: https://github.com/kryptoslab/slimcoin/commit/d9fad6ec8acef772f1d68c75159a0c74a3279814

Cheers

Graham

[bobitza202]

Recent statement from Novaexchange:


"2018-01-14 14:23 - Nova will NOT close its doors!
Honoured customers and crypto currency enthusiasts! You have been told a while ago now that we were planning to close down Nova Exchange in the beginning of 2018. We made this tough decision because Nova Exchange was growing at a speed, and in a way, that us, the founders, could not keep up with and run the business in a meaningful and secure way. Not wanting to make promises we might not be able to keep, we didn’t tell anyone, not anyone, that we never stopped looking for a way to keep going and keep Nova Exchange in business. So! We are so happy to announce that we have found a partner, a new main shareholder, willing and more importantly, able to carry on running Nova Exchange. The new owners, we have made sure, have the resources and the experience (6+ years in the business) it takes to provide excellent service to you all. We started negotiations and talks early in November last year, and now we can tell you the good news: The show will go on! More information will follow. In the meantime, just go keep on trading crypto. Best Wishes to you all!"

Maybe this could mean good news for Slimcoin if trading would start again  

Wish i had deposited some BTC before deposits got disabled, some will get lucky with those sell orders going as low as 80 sats, there's a nice 100k SLM sell order for about 0.2BTC, that's a good deal  

[coin2.0]

Recent statement from Novaexchange:


"2018-01-14 14:23 - Nova will NOT close its doors!
Honoured customers and crypto currency enthusiasts! You have been told a while ago now that we were planning to close down Nova Exchange in the beginning of 2018. We made this tough decision because Nova Exchange was growing at a speed, and in a way, that us, the founders, could not keep up with and run the business in a meaningful and secure way. Not wanting to make promises we might not be able to keep, we didn’t tell anyone, not anyone, that we never stopped looking for a way to keep going and keep Nova Exchange in business. So! We are so happy to announce that we have found a partner, a new main shareholder, willing and more importantly, able to carry on running Nova Exchange. The new owners, we have made sure, have the resources and the experience (6+ years in the business) it takes to provide excellent service to you all. We started negotiations and talks early in November last year, and now we can tell you the good news: The show will go on! More information will follow. In the meantime, just go keep on trading crypto. Best Wishes to you all!"

Maybe this could mean good news for Slimcoin if trading would start again  

Wish i had deposited some BTC before deposits got disabled, some will get lucky with those sell orders going as low as 80 sats, there's a nice 100k SLM sell order for about 0.2BTC, that's a good deal  

yes,there have a nice sell order,while i cant deposit BTC now.

[gjhiggins]

If anyone's interested in making a non-technical contribution to the group ...

A pointer to the bitcoin wiki entry for Proof-of-Burn was posted to HN recently (without comment) and I noticed that the link to the Slimcoin white paper that appears in the bitcoin wiki entry needs editing because currently it unfortunately references the now-unresolving address: http://www.slimcoin.club/whitepaper.pdf.

I'd do it myself but that would be hogging all the fun.

Cheers

Graham

[gjhiggins]

Further to using OP_RETURN data to carry immutable resolvable references to externally hosted content, I'm also exploring options available via IPFS ...

https://neocities.org/

https://blog.neocities.org/blog/2017/08/07/ipfs-dns-support.html

https://ipfs.io/docs/install/

Cheers

Graham

[d5000]

A pointer to the bitcoin wiki entry for Proof-of-Burn was posted to HN recently (without comment) and I noticed that the link to the Slimcoin white paper that appears in the bitcoin wiki entry needs editing because currently it unfortunately references the now-unresolving address: http://www.slimcoin.club/whitepaper.pdf.

Done, thanks for advising.

IPFS is very interesting as an alternative to a standard bittorrent swarm; if they manage to make it easy to access it for non-technical users without non-standard software it can be a good complement to the "traditional" web2web method via WebTorrent. I read they have already a relatively easy-to-use browser extension, but I haven't tested it.

[gjhiggins]

I should've bided my time ... I'd followed the destructions to get ipfs running on my XPS, left it idle and have returned a few hours later to find my HD at 100% usage, apps and altcoin clients falling over everywhere, the logging system hysterically shrieking at the console and /var/lib/docker sat at 461Gb.

It may just be coincidence and not down to ipfs, depends if docker is implicated - I don't believe I'm running any docker apps and I certainly haven't created any myself, so why it used nearly half a terabyte is beyond me atm.

Caution is advised, as ever. I'll report back once I've scrubbed things clean.

Cheers

Graham

[gjhiggins]

It may just be coincidence and not down to ipfs, depends if docker is implicated - I don't believe I'm running any docker apps and I certainly haven't created any myself, so why it used nearly half a terabyte is beyond me atm.

Yes, it was just coincidence, I'd had a look at timemachine, a Linux backup app and had apparently inadvertently enabled it, along with its default config to back up on the HD. I've reinstalled ipfs.

w.r.t. my committed boost 1.66 compat fix: https://github.com/slimcoin-project/Slimcoin/commit/bb6c7a3ce5fb4e0b714fee72ce87b0ebd74aa136, it'll be worth keeping an eye on the solution for this Verge issue raised on the same problem: https://github.com/vergecurrency/VERGE/issues/418

I doubt whether anyone runs that code anyway, it implements SSL for RPC calls and was removed entirely in 0.12 Core along with the dependency on openssl.

Cheers

Graham

[SHBlizzard]

looks like good tech.. will buy in soon

[muf18]

Remove coinhouse they are probably dishonest, their wallet isn't working not responding for tickets.
Imo for now they are scammers, with my 1000SLM.

[gjhiggins]

I recently went through the whitepaper of Gulden, which I found very interesting because of two reasons.
Find it here
First I learned quite a lot about blockchain technology and second I wondered if some of the development for the PoW2 could be used for Slimcoin too.

I'm just playing with ideas but I assumed that maybe Gulden in case of a snapshot scenario would be a lot closer to what Slimcoin aims to.

That's a good find - better than most on blockchain tech but, as is characteristic of altcoin “white papers”, its loose writing and appeals to bogus “common knowledge” tends to undermine my confidence in the entire effort. e.g. this completely unnecessary and laughably false inference ... “PoS has a potential flaw that has been described as the ’nothing at stake’ problem, it is commonly misunderstood and therefore many think it is a myth.” It makes for uncomfortable reading in what purports to be a serious discourse on cryptocurrency.

Otherwise, it's an interesting approach, attempting to harmonise the otherwise competing interests of those who mine and those who stake in a way that also enhances network security and robustness.

Unfortunately, the intersection of Witness/PoW/PoB will significantly complicate any implementation and, as Slimcoin is a bespoke variant reference client for the Bitcoin protocol, will require a correspondingly significant amount of not just professional competence in C++ but also professional-grade software engineering skills.

Cheers

Graham

[biplobmbhr]

I am feeling very weird about this project! What benefits does the blockchain gives to it?

[gjhiggins]

I am feeling very weird about this project! What benefits does the blockchain gives to it?

In general on bitcointalk, every thread devoted to a specific altcoin (aka “ANN”, an abbreviation of “Announcement”) carries at least some details of the coin and pertinent matters of interest to an assumed would-be new member of the coin's user community. In this instance ... https://bitcointalk.org/index.php?topic=1141676.0 and ...

Slimcoin is a energy-saving, fast-confirming and novel cryptocurrency. It is the first cryptocurrency using Proof of Burn for block generation and currency distribution - a distribution mechanism with interesting economic properties. Proof of Burn is combined with Proof of Work and Proof of Stake to increase security. Another highlight is the DCrypt algorithm, which is one of the most difficult algorithms to implement in an ASIC and suitable for CPU and GPU mining.

Slimcoin is a P2P project - we have no "official dev", nor it is managed by any centralized entity or organization. There was no premine at the start. You can contribute with coding, testing, providing goods & services or simply using it. Be welcome!

Were you a human, you would/should be aware of that. However, of late a substantial number of account-farming bots have been making ill-written posts masquerading as posts from humans with ESL (English as a Second Language, i.e. non-native speakers).

I regret to inform you that your post has failed the Turing test and so has received a stock textual answer.

Cheers

Graham

[gjhiggins]

Remove coinhouse they are probably dishonest, their wallet isn't working not responding for tickets.
Imo for now they are scammers, with my 1000SLM.

I deposited 10 SLM and ACME shows the tx details:

http://tessier.bel-epa.com:5064/main/tx/dcd4787ae7d870884d7bd75c1b44988fa424669b85bf0a423c40eba10919e73f

Let's see how that goes ...

Cheers

Graham

[d5000]

Regarding to Coinhouse, I googled a bit and found an user that had similar problems with the "Electra" cryptocurrency and accused them as scammers (yes, it was coinhouse.eu, not coinhouse.com/io), but the issue seems to have been solved then.

So it's maybe to early to qualify them as scammers, but as Graham already found out their company structure does not seem very trustworthy. Maybe it's better to include Freiexchange in the website instead of them, until the issue is resolved.

I've drafted a new version for the blocknotify script with a basic "reorg check" that compares the blockchain hashes of the previous block at the RDF chain and the original Slimcoin chain, and am testing it now. I've had restructured it a bit, separating a "block graph" and a "chain graph" to be able to add and delete entire blocks to the RDF chain graph with the Fuseki scripts, but now I realize that this was most likely unnecessary  as I could have used RDFLib methods for that distinction ... I'll see if the distinction makes sense or not.

[gjhiggins]

I've drafted a new version for the blocknotify script ...

I need to commit a small change, you can make it yourself if you haven't sussed it already. There's a(n obvious, when you think about it, so I shoulda known) modal change when going from catchup to blocknotify. The two blocks at either end of the chain are special, the genesis block has no value bound to previousblockhash and the last block minted has no value bound to nextblockhash. That is to say, the getblock data retrieved via blocknotify doesn't (and cannot) have a nextblockhash. So, every time ACME retrieves a block, it also has to bind the previous block's nextblockhash to the newly-retrieved block's hash.

In blocknotifybase.py, edit readblock (the last method) as follows:


           elif k == 'previousblockhash':
                self.g.add(
                    (block, URIRef(blockprops.get(k)),
                        URIRef(CCY['C' + val])))
+               self.g.add(
+                   (URIRef(CCY['C' + val]),
+                       blockprops.get('nextblockhash'), block))
            elif k == 'nextblockhash' and val is not None:
                self.g.add(
                    (block, URIRef(blockprops.get(k)),
                        URIRef(CCY['C' + val])))
            elif k == 'version' and val == 1:
                pass



Fuseki's “manage databases” tab offers “backup” - which creates a compressed archive of the graph in ${FUSEKI_HOME}/run/backups, e.g. slimcoin_2017-09-26_21-22-14.nq.gz.

For getting the dump restored (on my local instance of fuseki), I tried this: https://github.com/UKGovLD/registry-core/wiki/Operation#restore-a-database-dump (first stopping fuseki, doing the restore, then starting it again) .. 

Restore a database dump
Rebuild the store from a dump file using the Apache Jena command line tools.

tdbloader --loc tempstore slimcoin-{timestamp}.nq.gz
rm -rf /opt/acme/fuseki/run/databases/slimcoin
mv tempstore /opt/acme/fuseki/run/databases/slimcoin

Worked a treat, potentially scriptable.

SPARQL also allows CONSTRUCT statements, which allows you to construct a subgraph, so your optimised version could, in principle (haven't actually tried it) be CONSTRUCTED from the complete mapping. I found this SPARQL cheatsheet which hints at the possibilities: http://www.iro.umontreal.ca/~lapalme/ift6281/sparql-1_1-cheat-sheet.pdf

And this is where I'm currently headed, will write it up soon ...

Kuhn, Tobias & Dumontier, Michel. (2014). Trusty URIs: Verifiable, Immutable, and Permanent Digital Artifacts for Linked Data. ESWC. . . 10.1007/978-3-319-07443-6_27.

To make digital resources on the web verifiable, immutable, and permanent, we propose a technique to include cryptographic hash values in URIs. We call them trusty URIs and we show how they can be used for approaches like nanopublications to make not only specific resources but their entire reference trees verifiable. Digital artifacts can be identified not only on the byte level but on more abstract levels such as RDF graphs, which means that resources keep their hash values even when presented in a different format. Our approach sticks to the core principles of the web, namely openness and decentralized architecture, is fully compatible with existing standards and protocols, and can therefore be used right away. Evaluation of our reference implementations shows that these desired properties are indeed accomplished by our approach, and that it remains practical even for very large files.

https://www.researchgate.net/publication/259845637_Trusty_URIs_Verifiable_Immutable_and_Permanent_Digital_Artifacts_for_Linked_Data

Usefully, they provide a Python implementation to just pick up and run with: https://github.com/trustyuri/trustyuri-python

Dependencies
You have to install the rdflib package:

$ pip install rdflib

Of course you do, it's the best-of-breed (https://github.com/RDFLib/rdflib/graphs/contributors) <smug>

Cheers

Graham

[d5000]

Thanks Graham! I have updated my version of the blocknotify script with your addition. I consider the scripts (blocknotifybase and a catchup/notify cli script I call for now block2rdf-cli) still not "publishable", because I'm still experimenting which one could be the best structure to allow partial chain graphs (for now, an OP_RETURN graph for a fast-searchable publications/inscriptions index, and a "burn address balance" graph) and the code is still pretty ugly

I'll look into the paper you provided. I'm currently thinking about a method for an "extension" of simple web2web pages for a "monetization" service, and maybe signed RDF graphs could be part of the solution.

In particular, I thought about a system of two "assets": One, a "power asset", is tracking the burnt coins of each user and allows everybody that has burnt coins to "give power" to other Slimcoin users that are using that extension - principally to "tip" content creators. It would be pretty similar to what Steem calls "steem power", but with one difference: This "power asset" would decay like the PoB coins that are "backing" them, to avoid the formation of a "permanent nobility". But it would be possible to "trade" them via a long term trade to another asset that does not decay and thus is inflationary (like the "Steem" token in Steem).

It would be, thus, a very "slimcoinish" monetization system, as it would be intrinsically interwoven with Proof of Burn.

A big difference to Steem would be, obviously, that contents aren't expected to live on the blockchain but in torrent networks and/or IPFS. @ksdme has drafted a nice extension for web2web that would allow big, updateable websites without having to store all changes to the blockchain.