Slimcoin | First Proof of Burn currency | Decentralized Web

[d5000]

I have removed Coinhouse (until their problem is solved) and Coinsmarkets (offline/with problems since the beginning of January) from both the website and the OP of this thread. Instead I added Freiexchange to the website (something I forgot some days ago) and I mean to remember that Graham said they looked more trustworthy than the other two.

At least with Coinhouse the situation maybe can be solved:

Coinhouse can't make daemon from master branch:
It looks like we cannot clone that somehow
"We are not able to clone a piece of a repository"

Do they use Linux or Windows? If they use Linux, ask for the distribution and architecture they use. Someone of us (if they're using AMD64, then me) then could compile a daemon for them.

But they really should be able to compile a client if they are an serious exchange business, or not? So if they cannot clone the master branch they should use one of the source code packages from the Slimcoin Releases page (0.5 should be recent enough).

[1714911219]

1714911219

[1714911219]

1714911219

[1714911219]

1714911219

[1714911219]

1714911219

[muf18]

Lol they are using 0.4.1, I told them to use 0.5 from master branch. And they don't...

Hi Slimcoin Community,

Sorry its taking long i have looked in to it and this our wallet from getinfo

"version" : "SLMv0.4.1-alpha-8-g79cecee-alpha",
"protocolversion" : 60004,
"walletversion" : 60000,
"balance" : 0.00000000,
"newmint" : 0.00000000,
"stake" : 0.00000000,
"blocks" : 1201884,
"moneysupply" : 18008252.40327000,
"connections" : 7,
"proxy" : "",
"ip" : "84.245.49.92",
"difficulty" : 0.19553056,
"testnet" : false,
"keypoololdest" : 1516848866,
"keypoolsize" : 101,
"paytxfee" : 0.01000000,
"errors" : "WARNING: Blockchain redownload required approaching or past v0.4 upgrade deadline."

I am redownloading the chain hope to fix the error.

Wil get back to you tonight!

Btw. I get response from Blockbid exchange:

Hi Piotr,
Thanks for your email.

Yes, we'd love to list Slimcoin for the bronze package (free listing).

All you need to do is fill out the coin listing form via this link: https://goo.gl/forms/TgyNHsFVz8nAWojw2

Our team will then review the coin and get in touch in the next few weeks to finalise onboarding.

Thanks,
Emma

Will you help me to fill-in form?

Third news: I'm going for a private meeting with CTO of abucoins.pl, to discuss about our project, our decentralized team, and technical details.
Do you have ideas, I should tell, I will now compose some notes. Any input will be appreciated.

[gjhiggins]

Hi muf18,
Thanks for your email.

Yes, we'd love to list Slimcoin for the bronze package (free listing).

All you need to do is fill out the coin listing form via this link: https://goo.gl/forms/TgyNHsFVz8nAWojw2

Our team will then review the coin and get in touch in the next few weeks to finalise onboarding.

Thanks,
Emma

Will you help me to fill-in form?

What is the name of your coin? - Slimcoin
Link to your coin's Coin Market Cap listing - https://coinmarketcap.com/currencies/slimcoin/
Primary Contact Information (name and email)
Secondary Contact Information (name and email)
Description of your coin - Slimcoin is an energy-saving, fast-confirming and novel cryptocurrency, 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.
Coin trading symbol/ticker - SLM
Coin Launch Date - 05/08/2014
Github Link - https://github.com/slimcoin-project/Slimcoin
Website Link - http://www.slimcoin.club/
Social Media Links - https://www.reddit.com/r/slimcoin/

I assume that primary and secondary contacts refer to exchange account holders.

Cheers

Graham

[d5000]

@all:

Is there any problem if I change the default branch of the repo to "master" to prevent people cloning the (outdated) "slimcoin" branch like the Coinhouse people did?

BTW: The "reorg-aware" blocknotify script is almost ready, I'm still struggling a bit with the CONSTRUCT query to delete an entire block from the RDF chain (see this post), but I think I have found a workaround, so soon there will be real-time web2web/inscription testing possible.

[muf18]

I don't know, but I don't think there is a problem.
I think it's more of a problem with coinhouse exchange, as @gjhiggins told.
I have submitted request to Blockbid exchange, will see what they will respond.

I have heared, that Binance wants 90K USD for listing. LOL XD, good joke.

[d5000]

I finally discovered the problem that led to the failed CONSTRUCT queries. I had tested the query with block 1 that on Graham's server most likely had been created by an old version of the blocknotify script. In other blocks the script wasn't adding "blockhash" at all to the transaction subgraphs because "blockhash" was missing in the txkeys dictionary.  Fixed that, and now the query finally works

(That means however that I will have to re-sync the whole RDF blockchain again, which could take some days or even weeks. But I will provide a light dataset for Web2web tests, with only the blocks that contain inscriptions, which are very few as of now.)

I got also another error because on the "nextblockhash" addition an URIRef() was missing. Slowly I begin to understand RDFLib ...


Regarding Coinsmarkets, they are updating a "news" page, so maybe it's not totally lost, but they seem to be a very small exchange with only 4 or 5 employees, so until they're up again some patience is needed ...

Well, for now we have Freiexchange (which may have low volume but seems OK so far), so SLM can be bought more easily than Cryptonite (if you're not a Thai citizen or resident) ...

[muf18]

Bold move by stocks.exchange - they have propped price to 1BTC.
It's just amazing, that they are asking for 0.5-1% of their daily vol, to be listed.

If there is no response from yobit, I will try to contact them one more time, and see.
Freiexchange is a little hard, but I guess it's only one, which we can afford for now.

[muf18]

I have talked to abucoins CTO.
I talked about Slimcoin, a little, about cryptocurrencies space and so on.
He said that he will be interested after, they widen their offer of popular tokens, to talk about adding us too, in 6-8 months time.

It's a good sign, he said, that he see us, as knowledgeable team of guys, and he like the idea.
He said, that he also see ERC-20 tokens, and ICOs as something, which is going to far.


Btw. - BCH original chain ? https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf

[gjhiggins]

Btw. - BCH original chain ? https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf

Oddly amateurish, given its origin and embarrassingly, obviously, wrong in some areas. The language used naively testifies both to the underlying prejudices and to a raft of woefully unchallenged assumptions, I'll just pick one out at random: “The phrase ... is often exclaimed” (my emphasis) is worded as a totally unnecessary (and worse, unsupported) value judgment, i.e. the authors choose to use “exclaimed”, rather than the accurate and perfectly serviceable but far less bombastic, “claimed”. This unforced error stands as mute testimony to the underlying narrative that is driving the discourse. Not only are they misleading their audience, they miss the entire crux of the matter ...

“A common misconception is that permissionless blockchains are systems without control and ownership. The phrase “no one controls a blockchain!” is often exclaimed; however, while no user, government, or country controls a blockchain, there is still a group of core developers who are responsible for the system’s development. These developers may act in the interest of the community at large, but they still maintain some level of control.”

Which prompts me immediately to seek an answer to the important question implied but not actually raised in the statement “they still maintain some level of control”.

Er, how much is some exactly? A lot, a little, barely any, as much as any other user? Is there anything useful that can be wrung out of this otherwise unmerited claim? Got any hard statistics? Didn't think so. Any support at all for this contention other than “it stands to reason, dunnit?” Didn't think so. Done any broader background investigation of organisational models based on principles of decentralisation --- such as Teal? Didn't think so. And what are these misconceptions about ownership that are claimed to exist: “A common misconception is that permissionless blockchains are systems without control and ownership.” Why introduce the claim and then completely fail to even mention it further? Elsewhere in the domain of cryptocurrency, such casually-made unsupported derogatory statements are accurately called out as FUD.

As far as “dev control” goes - you can work out the reality for yourself from your own experience in Slimcoin, interacting with the “group of core developers who are responsible for the system’s development” and who “still maintain some level of control”. Actually, I wouldn't mind having a word with the Slimcoin core developer team myself --- has anyone seen them around recently? I mean, if the authors are correct, then “there is still a group of core developers who are responsible for the system’s development”, so where's Slimcoin’s?

By contrast, there's much more meat in Paradigm shifts for the decentralized Web (albeit a bit of a high-level view and so less useful to Slimcoin now that we've moved on to dealing with the practicalities of the approach but may be more accessible than my typically impenetrable articulations) and the associated HN discussion which, when read in conjunction with my notion for using the Slimcoin blockchain to publish indexes to signed RDF graphs, contains some near misses and also some hits --- but the latter with notions too vaguely formulated to have any real impact.

Cheers

Graham

[GTTIGER]

I have talked to abucoins CTO.
I talked about Slimcoin, a little, about cryptocurrencies space and so on.
He said that he will be interested after, they widen their offer of popular tokens, to talk about adding us too, in 6-8 months time.



It's a good sign, he said, that he see us, as knowledgeable team of guys, and he like the idea.
He said, that he also see ERC-20 tokens, and ICOs as something, which is going to far.


Btw. - BCH original chain ? https://csrc.nist.gov/CSRC/media/Publications/nistir/8202/draft/documents/nistir8202-draft.pdf

Cool! I see it being a good symbiotic relationship. The exchange might get more volume. While we get more liquidity.

[d5000]

Paradigm shifts for the decentralized Web

Thank you for that link. It reminded me to some tests I made - some months ago - with Hubzilla (the successor of Friendica / Red Matrix, a "decentralized" social network), which uses the ZOT library to provide a "nomadic identity". That could be described as a hybrid model between the Solid approach (everybody stores his/her data on his own) and the Mastodon approach (multiple users on one server). Users in Hubzilla can change from the "lazy" Mastodon approach to the more demanding Solid approach at any time "cloning" their data sets; they can also wander around between distinct "group" servers.

In the current "Slimweb" incarnation (web2web-based) identity would be linked primarily to private keys; it would be worth discussing if a second "identity layer" could be provided; for example, one primary address identified with an "online identity" which stores inscriptions leading to other addresses following distinct publications of that person, being the relationships between these publications stored in signed RDF graphs.

BTW. the new blocknotify script now has been tested with "reorganized" small fake RDF blockchains and so far works well recognizing and "repairing" reorgs. I'll conduct some more tests with partial blockchains containing only blocks and transactions with OP_RETURN inscriptions this week, then activate the new script on my VPS with Fuseki (the one that is accessible via the "Slimweb gateway").

Once it is fully synced, real-time web2web testing will be finally possible. That means basically that when you publish something via an OP_RETURN inscription, web2web apps like the Gateway will find the corresponding Torrent hash about 2 minutes later. I would consider it still alpha software, however.

PS: CoinsMarkets seems to be back, but has still problems.

[gjhiggins]

Thank you for that link. It reminded me to some tests I made - some months ago - with Hubzilla (the successor of Friendica / Red Matrix, a "decentralized" social network), which uses the ZOT library to provide a "nomadic identity". That could be described as a hybrid model between the Solid approach (everybody stores his/her data on his own) and the Mastodon approach (multiple users on one server). Users in Hubzilla can change from the "lazy" Mastodon approach to the more demanding Solid approach at any time "cloning" their data sets; they can also wander around between distinct "group" servers.

I was ignorant about Hubzilla previously; having skimmed the narrative description of the Zot protocol, fwiw I think you're spot on. They summarise it as “a JSON-based web framework for implementing secure decentralised communications and services.” and I would characterise the SOLID approach as “a JSONLD-based web framework for implementing secure decentralised communications and services.” Only two letters extra but it makes a big difference in terms of opening up access to already worked-out solutions.

In the current "Slimweb" incarnation (web2web-based) identity would be linked primarily to private keys; it would be worth discussing if a second "identity layer" could be provided; for example, one primary address identified with an "online identity" which stores inscriptions leading to other addresses following distinct publications of that person, being the relationships between these publications stored in signed RDF graphs.

My conceptualisation runs as follows:

I create a convention by using the in-browser bip39 HD keygen implementation to create a handful of notional "identity” addresses at sub-level m/44'/63'/0'/8/*, one for each identity that I wish to distinguish - as exemplified below (each one given a label for convenient reference):

m/44'/63'/0'/8/0	Sa3evx12ZgTDHqvuT5xpBaAYA5PQAmZFDM	gjhiggins
m/44'/63'/0'/8/1	SffwZ6jriJbnYtB27hbA9SzhpWYqf8WdoT	minki
m/44'/63'/0'/8/2	SYXxitjEU4KjVoXSrLLPwUhxEzpdjNr6Ud	gj

(I'm complicating matters slightly by using a bip39 wallet but the deterministic aspect means that re-entering the passphrase re-creates the privkeys for my identity addresses)

The convention continues ... in txouts spent by the “identity” addresses (e.g. Sa3evx12ZgTDHqvuT5xpBaAYA5PQAmZFDM), the OP_RETURN data is to be read as a ni-URI¹ formatted “Trusty URI”², e.g.

ni:///sha-256;5AbXdpz5DcaYXCh9l3eI9ruBosiL5XDU3rxBbBaUO70?module=RA

In the intended bog-standard modus operandi, the publisher will either self-host a SLM-ACME or will have a subscription to an SLM-ACME service hosted by a third-party and the  ni-URI value will resolve to a signed graph, retrieved by a SPARQL query posed of the graph:

SELECT ?g WHERE {
  ?g ccy:graphSignatureHash 5AbXdpz5DcaYXCh9l3eI9ruBosiL5XDU3rxBbBaUO70
}

The signed graph can contain whatever you like, as a file resource (module=FA) or an RDF document (module=RA). The latter makes more sense in a decentralised context where the need for apps to “discover” meta-data starts to become acute (happily, RDF documents are self-describing). Identity addresses would have to be published through sidechannels, such as this thread.

The minimum requirements of the SOLID WebId Profile would seem to be satisfiable, same goes for most of the SOLID-recommended vCard.

BTW. the new blocknotify script now has been tested with "reorganized" small fake RDF blockchains and so far works well recognizing and "repairing" reorgs. I'll conduct some more tests with partial blockchains containing only blocks and transactions with OP_RETURN inscriptions this week, then activate the new script on my VPS with Fuseki (the one that is accessible via the "Slimweb gateway").

Very cool. Sorry for the non-reply to your earlier question, I completely lost track of time - I didn't have an answer anyway.

Once it is fully synced, real-time web2web testing will be finally possible. That means basically that when you publish something via an OP_RETURN inscription, web2web apps like the Gateway will find the corresponding Torrent hash about 2 minutes later. I would consider it still alpha software, however.

Nice work.

Another direction in which to pursue the notion of using OP_RETURN data to carry resolvable pointers to content/metadata - there's a very accessible HN discussion of IPFS basics which is very pertinent, especially the comparison of IPFS and torrenting practilcalities.

“One thing I've failed to find out about IPFS: who pays for hosting? The user? Or is it donated by some peers?” - https://news.ycombinator.com/item?id=16078975

I think I mentioned, I gave IPFS a spin. IPFS locators as OP_RETURN data would also work. There's a javascript implementation with some interesting in-browser examples: https://github.com/ipfs/js-ipfs/tree/master/examples and a ipfs-api https://github.com/ipfs/js-ipfs-api. It's on my stack to investigate, using the resurrected neocities.org - https://neocities.org/api and their support for ipfs DNS - https://blog.neocities.org/blog/2017/08/07/ipfs-dns-support.html

I still think RDF has an overwhelmingly significant advantage in that the torrent and ipfs protocols are incapable of carrying metadata which necessitates the use of separate sidechannels for the communication of associated user-vital info such as title, creator etc.

Cheers

Graham

¹ https://datatracker.ietf.org/doc/rfc6920/ Naming Things with Hashes - RFC 6920

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

“Trusty URIs end with a hash value in Base64 notation(i.e. A–Z,a–z,0–9,-, and representing the numbers from 0 to 63) that is preceded by a module identifier. This is an example:

    http://example.org/r1.RA5AbXdpz5DcaYXCh9l3eI9ruBosiL5XDU3rxBbBaUO70”

[ylpkm2]

Any news on nvidia miner?

[d5000]

Only two letters extra but it makes a big difference in terms of opening up access to already worked-out solutions.

Yes, I have also noted that Hubzilla/ZOT doesn't support established Linked Data technologies natively. I have to look at Solid more closely, seems interesting.

Your concept for identities on the "Slimweb" looks very interesting, I have thought about something similar before but without your technical knowledge. Time to read

I don't know if you had contact with ksdme, who has worked on a concept to allow updateable websites where the updates don't need to be stored in the blockchain, combining timestamps with Torrent hashes. I hope both approaches are compatible (and I think so, as a trusty URI if I understand right could point easily to a timestamp/content-hash combination).

Maybe on the "Slimweb" several different approaches - simple torrent-based web2web with "blockchain as CMS", ksdme's concept of timestamped hashes, IPFS and your RDF/trusty URI-based identity concept - could coexist harmonically. Some of those methods are more beneficial for publishers (those that incentive automatic sharing of contents by participants, like IPFS), others for readers (those that don't require extra software, like traditional web2web). The challenge would be to provide a simple interface for publishers that included all methods.

[gjhiggins]

I have to look at Solid more closely, seems interesting.

Especially in view of the fact that a Core client also offers an HTTP RPC: https://github.com/bitcoin/bitcoin/blob/master/src/httprpc.cpp#L229

Paul Frazee gets a quote in the IBT's: (Decentralisation experts unpack the problems of 'Web 3.0' Nick Szabo, Zooko Wilcox and Paul Frazee talk about the goals and challenges of the next generation of the internet) http://www.ibtimes.co.uk/decentralisation-experts-unpack-problems-web-3-0-1658382

In terms of new technology to look out for, Frazee said he was quite surprised how much interesting stuff coming is out of standards bodies right now. "There's the Solid project, which is headed by Tim Berners-Lee; there's the WC3 social working group had been working on something called Activity Pub, and I think they're doing good work there."

However, just because the media are trialling a new narrative, it doesn't mean that there's any deep understanding there:

The Zcash Foundation wants to be a conduit through which the community can collectively decide and coordinate [...].

That would be a centralised decentralisation, wouldn't it? Splendidly absurdist nonsense.

Cheers

Graham

[d5000]

I am happy to announce that web2web publications can now be tested in real-time. The modified blocknotify script is working since about 48 hours without problems. I am still cleaning it up (there are still some "hacky" workarounds inside, I'll look if I find more elegant solutions) and then I'll publish it.

To test, you can use the Gateway: https://d5000.github.io/web2web/gateway.html

Mini-HowTo (you need a Slimcoin client and WebTorrent):

1. Create a HTML or text file.
2. Open WebTorrent. Create a new torrent file using the file created in Step 1 (File -> Create New Torrent from File ...).
3. Seed the torrent.
4. Copy the magnet link with the right mouse button.
5. Open Slimcoin-qt. Go to "Tools -> Inscribe", and enter the part of the magnet link that contains the hash (btih:XXX), including the magnet: prefix. Delete the ampersand after the hash (&) and everything behind it.

Example for a link that works (but likely the torrent won't be online, so create your own torrent!):

Code:

magnet:?xt=urn:btih:1dac4fba51188b76bb467576dd374780f1e7c7a6

6. Wait about 2 minutes until the transaction gets confirmed (remember we have a block time of 90 secs).
7. Open the Gateway.
8. Insert the Slimcoin address from which you sent the transaction (if unsure, check the transaction hash and open it in a block explorer like ACME or bchain.info) in the form field.
9. Very likely you must now disable the blocking of "mixed content" (I'll try to solve that problem in the next days).
10. Click on the button and wait. A moment later, you should see "torrent hash found", followed by the hash, and then if it finds the torrent you will see the file you created in the first step. If not, you can leave the Gateway tab open and wait a bit until it's well known to trackers.

(I have changed the dataset name to pub_slmchain because my VPS is now serving a "partial blockchain" to improve performance, the dataset does only contain blocks with OP_RETURN transactions. Eventually I will make the full blockchain dataset available again, but it must resync fully and that will take some time; first I will conduct tests with the partial chain.)

[keliokan]

Hi all,

I just have a question about the equilibrium between POW - POS and POB.
For example on the last 100 blocks found (1256267 - xxxx367) , 12 are PoW, 5 are PoB and 83 are PoS.
Clearly we can correlate this difference with the amount of minted and burned coins (about 10 times lower).  (supply: 16239895  (mint: 18278765 - burn: 2038870))
I can also understand that because the hashrate seems quite low (around 2 mhash at this time) the PoW is under-represented.

If i am not wrong, these 3 proofs system represents a way to prevent attacks on the blockchain.
The PoS does represent more than 50% of the blocks, what if someone posses more than 50%... ?

Thanks,

K.

[muf18]

Hi all,

I just have a question about the equilibrium between POW - POS and POB.
For example on the last 100 blocks found (1256267 - xxxx367) , 12 are PoW, 5 are PoB and 83 are PoS.
Clearly we can correlate this difference with the amount of minted and burned coins (about 10 times lower).  (supply: 16239895  (mint: 18278765 - burn: 2038870))
I can also understand that because the hashrate seems quite low (around 2 mhash at this time) the PoW is under-represented.

If i am not wrong, these 3 proofs system represents a way to prevent attacks on the blockchain.
The PoS does represent more than 50% of the blocks, what if someone posses more than 50%... ?

Thanks,

K.

PoS blocks are timed - if you didn't PoSed for long time, you will get a lot of blocks within a few hours/days.
Then it deflate and return to normal.
There was a proposal to change to newer algorythm, which wouldn't involve time just your stake, and that variable such as time wouldn't be important.

[muf18]

https://www.youtube.com/watch?time_continue=3&v=gWW3cwcthQo

[gjhiggins]

If i am not wrong, these 3 proofs system represents a way to prevent attacks on the blockchain.

That's the understanding I'm arriving at, with a similar degree of caution.

There's a useful level of detail on consensus mechanisms in SoK: Consensus in the Age of Blockchains if you skip to p7, “1) Attacks and Mitigation”

(Sloppy on “Slimcode” tho' --- yes, they do mean us. It's a shame that their shallow approach to the domain beguiled them into making a completely unnecessary incorrect assertion. I mean, why did they even bother to make the statement? It speaks to me of research bias --- been there, got the T-shirt. And I find it useful to bear that in mind when reading, hence the pointer to that specific section - the rest of the paper is a mixed bag.)

Cheers

Graham