Slimcoin | First Proof of Burn currency | Decentralized Web

[d5000]

I think a merger of slimcoin.club and slimco.in is not needed. Slimcoin.club is a private site, and that's totally ok, while slimco.in is the "project web presence", directly connected with the Github project presence.

Regarding PoS, I agree basically with muf18 to lower the reward. That would require a hard fork, but if we plan it carefully (maybe for mid-2018) then perhaps we could optimize the whole PoS system to fix some of its flaws. 

In the last weeks, after the event when several PoS blocks were published in a row when a big staker connected his wallet, I thought about some aspects of PoS. A solution to avoid this kind of events could be to give PoS blocks less "chain trust", but maybe it's better to reduce chain trust more than now if more than e.g. 5 PoS blocks appear in a row. The reason for that proposal is that Peercoin's PoS is the weakest of Slimcoin's algorithms. I would also change to a simpler PoS mechanism like Blackcoin's (the one used by Particl).

Regarding the roadmap: I've looked into Navcoin again and perhaps it isn't the best option to port a 0.13+ Slimcoin version from because they've added some "privacy" features which require a second "layer" (from their whitepaper: "a secondary blockchain known as the Subchain"). This looks like a pretty non-standard and unproven solution Slim shouldn't copy.  Particl also seems to have a "privacy layer". It's perhaps possible to only port the Proof of Stake part and use standard Bitcoin code for the rest. I'm however still hoping for Peercoin to accelerate development - their Github is active but they will first switch to 0.8/0.9 code and then to 0.13+.

[gjhiggins]

I propose loose roadmap for now, as a 'goals' we should go into, and make happen:

Great idea.

1/ Web2Web and ACME integration - M1

This is ... (sucks finger, holds it in the air) ... about 75% complete. I'm currently concluding my “is metadata really an answer?” investigation after gaining some rough understanding of what's been apparently holding Datacoin back because a few years ago, all the elements seemed to be in place ... https://bitcointalk.org/index.php?topic=405992.0;all (only 4pp in all but it does comprehensively cover the issues). What I'm currently pondering is: limit display of (potentially raw sewage) to IsMine() addys (no work entailed) or a configurable whitelist (GUI work entailed).

2/ Test network for segwit/porting from nav coin/particl - M2

This is where my “different perspective on cryptocurrency” pays off by giving me more accurate projections. To achieve the proposed goal, the code implementing the tripartite minting will have to be rewritten in the new codebase and it would entail a hard fork, earlier clients will not be able to connect to the new blockchain. I predict that this will result in two networks, the original (dare I write “classic”?) and the new. (Go peer over the fence, In the case of both Ethereum and Bitcoin and a few other minor alts the new blockchain evolved as a separate entity co-existing with the original chain. So “evolutionary growth”, as expected from a Teal organisation and not “civil war” as expected from a hierarchy.) Note how many current Slimcoin users are quite comfortable with the old 0.3 version of the code and note that no-one can force them to upgrade, nor can sanctions be applied.

3/ Android Wallet - M3

Another major rewrite, I'm afraid, in order to extend the client to handle PoB.

4/ Smart contracts integration - test network - M4

Sure, but again, not the (sadly, hopelessly wrong) direction in which everyone else appears to be headed. I already know that road leads to a sticky end.

(I find myself slightly shocked at some of the more egregious NIH failures exhibited by “the kids of today” - f'rinstance, all this business about ML algos picking up unwanted human biases was well-known in the mid-80s. ML-driven credit-scoring implementations in the US had already run afoul of what the USians call “red-lining”, a corporate optimisation and exploitation of the deleterious effects of social deprivation that was so pernicious that they had to pass laws to prohibit it. All the ML systems had “learned” was how to exploit vulnerable people, which they've done all over again because the current population of ML “hotshots” are, unfortunately, no such thing, as they have just demonstrated in spades that they themselves are too SQD* to be able to learn from others' previous mistakes and so they advertise openly that they are inherently incapable of designing ML systems, hence the general conclusion, “Oh, GIGO”). * I'm struggling to find a non value-laden term and “Systematising Quotient Dominant” is the best I can manage, although “Autistic-spectrum dominant” is more accurately descriptive.

I see similar inadequate shallow models at play in the domain that is over-broadly painted as “smart contracts” and I can see the same mistakes being made again - because SQD's have a weakness for focusing on the internal consistency of their models and failing to cross-reference the resulting simplified model with the complex models of inconsistent reality. The lawyer's slides in that slideset I posted a week or so ago contain a lot of cautionary material which did not pass me by.

I've already had a very encouraging chat with Steve (close friend and Labs oppo for pretty much the entire decade that we were both there) as to whether he agreed with my tentative assessment that Ginger would be an appropriate approach...

Ginger is our attempt to build an elegant but friendly and practical programming system. It includes a programming language, virtual machine and supporting tools.

The programming language itself is syntax-neutral. By this we mean that you can choose any of several 'pluggable' front-end syntaxes - there's one rather like Algol/Pascal, another like Javascript, another like Lisp. They all get turned into an elegant back-end XML syntax.

Ginger is a modern programming language supporting automatic memory management, object oriented programming, pervasive multiple values and a simple but powerful data loading mechanism that includes data-format conversion.

Ginger is engineered to run on UNIX systems and is developed on OS X and Linux. Adapting it for other UNIXs is straightforward though.

Basically, the Bitcoin scripting language (described by gmaxwell as “adequately expressive for ‘smart contracts’” and that's one dude whose technical assessment I'm happy to take at face value) is too low-level for general use and so I would use Ginger to create a set of higher-level abstractions that were more attuned to end-user needs and more tractable to work with. Steve agrees that a Turing-complete language is not what you'd want for this task and has basically “given the nod” to my idea of using Ginger and has even offered some assistance. It's down to me to identify, characterise and implement the higher-level abstractions. The approach would still reap the benefits of the computational predictability of the Bitcoin scripting language (just don’t ask Steve for his opinion of it, he's not as charitable as I am) but would be able offer more domain-focused and programmer-friendly abstractions with all the advantages that Ginger brings. (And yes, you did read that correctly, you can write in whatever syntax suits: Javascript, Lisp, Scheme, Pascal, Python, it all compiles down to an elegant back-end XML syntax.)

Where am I going for the higher-level abstractions? Well my first port of call is the 2004 W3C Choreography Description Language effort (sunk by MS pulling out I 'spect). If nothing else, it should give me a useful notational starting point, saves me having to start at Level 0.

The Web Services Choreography Description Language (WS-CDL) is an XML-based language that describes peer-to-peer collaborations of participants by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal.

The Web Services specifications offer a communication bridge between the heterogeneous computational environments used to develop and host applications. The future of E-Business applications requires the ability to perform long-lived, peer-to-peer collaborations between the participating services, within or across the trusted domains of an organization.

The Web Services Choreography specification is targeted for composing interoperable, peer-to-peer collaborations between any type of participant regardless of the supporting platform or programming model used by the implementation of the hosting environment.

5/ LN test network - M5

Unexplored territory for me, can't really comment.


I'll limit this post to specific observations on the mooted “road map”.

Cheers

Graham

[muf18]

Great that most of my points are welcomed with enthusiasm.
I know that Segwit, and especially Lighting Network, will be hard to implement, and would require a hard-fork, but I think we can contact nova, and most miners are mining at v.0.5, from what I know (only some seeds, are on the old version v.0.3.2 and probably just because they don't have to change it).
If we have approval of nova (and mostly we will get it), rest will switch over, because they know, we can't have 2 networks (and second blockchain won't get to any exchange) - it's much easier, with our small, microscopic network, than with such big networks like ETH or BTC, and even then, they must hard fork chain or continue old chain, which was abducted.

About Android Wallet - can't we make it to listen tx's and view POB blocks as a POW blocks, outside of course on different server (because ? Is it completly different? I'm not a developer or even programmer, but I thought, about sth like that.
Also we could use something different than BitcoinJ implementation - I have stumbled across quite a few bitcoin wallets github android sources.

[Sorai]

Great that most of my points are welcomed with enthusiasm.
I know that Segwit, and especially Lighting Network, will be hard to implement, and would require a hard-fork, but I think we can contact nova, and most miners are mining at v.0.5, from what I know (only some seeds, are on the old version v.0.3.2 and probably just because they don't have to change it).
If we have approval of nova (and mostly we will get it), rest will switch over, because they know, we can't have 2 networks (and second blockchain won't get to any exchange) - it's much easier, with our small, microscopic network, than with such big networks like ETH or BTC, and even then, they must hard fork chain or continue old chain, which was abducted.

About Android Wallet - can't we make it to listen tx's and view POB blocks as a POW blocks, outside of course on different server (because ? Is it completly different? I'm not a developer or even programmer, but I thought, about sth like that.
Also we could use something different than BitcoinJ implementation - I have stumbled across quite a few bitcoin wallets github android sources.

I can see how Segwit and Lighting Network might be nice to have, but I view Slimcoin more as I view Bitcoin: an investment-oriented currency rather than a transaction-oriented currency.  

As such, above all, to me we need to make sure Slimcoin is solid and stable.  

Slimcoin has three pillars. If one of them could use shoring up, as @d5000 suggests, it would seem well worth doing.  

[gjhiggins]

...

Well, just hitting M1 isn't going to be that easy. As I noted, Datacoin had all the right elements in place but few people were interested, even with the comparative luxury of 128Kb per tx. My sense is that the UX was too fragmentary to offer much appeal and, in consequence, failed to present a coherent narrative. The crux of the issue is metadata. Metadata tells you what's stored and how to access it. Without that metadata, all you can do is serially guess. The adaptation of ACME for Datacoin can use the RDF graph to carry the metadata, the blockchain carries the content. The adaptation of ACME for Slimcoin uses the RDF graph to carry both the metadata and the content, the blockchain carries only an index into the graph.

ACME is just a web app that marshals and presents data obtained by talking to the coin's JSON-API and Fuseki's SPARQL endpoint. The web app component can be relatively trivially re-implemented in a Javascript framework such as Angular or Vue.js and the functionality (i.e. ACME as you see it right now) embedded in a wallet tab. ACME in the wallet, with a configurable whitelist of publishers' addresses plus whatever metadata is retrievable to convey information about the author, title, topic, tags, need, I, go, on. Publishing is ... let's riff on this ... in ACME via a javascript-implemented interface, could even offer in-wallet blogging, hitting “post” submits the content for javascript processing - the content and associated metadata are rendered as RDF, signed and pushed up to the configured ACME SPARQL UPDATE endpoint to be stored in the graph - and the ACME publication API updated. You don't even have to make the inscription, that's done automatically. All you need as a Slimcoin user is an ACME API key and off you go. At some stage archiving and migration functionality can be added but it amounts to little more than hooking up buttons to a few SPARQL queries.

I guess torrent serving could also be made (an optional) part of the package, torrenting does hook into a substantial propagation community, although RDF definitely carries the day when it comes to the extent of the metadata and so can be readily “discovered”.

Which is why ACME will be a self-deploying, as-hands-off-as-I-can-make-it package. I suppose, with a following wind, this might be reasonably mistaken for the raw material for a masternode system an overlay network administered by hoomans instead of an algorithm. It'll have it's pros and cons but it might see some use.

Cheers

Graham

[Sorai]

...

Well, just hitting M1 isn't going to be that easy. As I noted, Datacoin had all the right elements in place but few people were interested, even with the comparative luxury of 128Kb per tx. My sense is that the UX was too fragmentary to offer much appeal and, in consequence, failed to present a coherent narrative. The crux of the issue is metadata. Metadata tells you what's stored and how to access it. Without that metadata, all you can do is serially guess. The adaptation of ACME for Datacoin can use the RDF graph to carry the metadata, the blockchain carries the content. The adaptation of ACME for Slimcoin uses the RDF graph to carry both the metadata and the content, the blockchain carries only an index into the graph.

ACME is just a web app that marshals and presents data obtained by talking to the coin's JSON-API and Fuseki's SPARQL endpoint. The web app component can be relatively trivially re-implemented in a Javascript framework such as Angular or Vue.js and the functionality (i.e. ACME as you see it right now) embedded in a wallet tab. ACME in the wallet, with a configurable whitelist of publishers' addresses plus whatever metadata is retrievable to convey information about the author, title, topic, tags, need, I, go, on. Publishing is ... let's riff on this ... in ACME via a javascript-implemented interface, could even offer in-wallet blogging, hitting “post” submits the content for javascript processing - the content and associated metadata are rendered as RDF, signed and pushed up to the configured ACME SPARQL UPDATE endpoint to be stored in the graph - and the ACME publication API updated. You don't even have to make the inscription, that's done automatically. All you need as a Slimcoin user is an ACME API key and off you go. At some stage archiving and migration functionality can be added but it amounts to little more than hooking up buttons to a few SPARQL queries.

I guess torrent serving could also be made (an optional) part of the package, torrenting does hook into a substantial propagation community, although RDF definitely carries the day when it comes to the extent of the metadata and so can be readily “discovered”.

Which is why ACME will be a self-deploying, as-hands-off-as-I-can-make-it package. I suppose, with a following wind, this might be reasonably mistaken for the raw material for a masternode system an overlay network administered by hoomans instead of an algorithm. It'll have it's pros and cons but it might see some use.

Cheers

Graham

Where will the ACME blog posts get published to?  Is it also a reader? 

Might the blog posts go a URL that Slimcoin will be hosting?   

[muf18]

...

Well, just hitting M1 isn't going to be that easy. As I noted, Datacoin had all the right elements in place but few people were interested, even with the comparative luxury of 128Kb per tx. My sense is that the UX was too fragmentary to offer much appeal and, in consequence, failed to present a coherent narrative. The crux of the issue is metadata. Metadata tells you what's stored and how to access it. Without that metadata, all you can do is serially guess. The adaptation of ACME for Datacoin can use the RDF graph to carry the metadata, the blockchain carries the content. The adaptation of ACME for Slimcoin uses the RDF graph to carry both the metadata and the content, the blockchain carries only an index into the graph.

ACME is just a web app that marshals and presents data obtained by talking to the coin's JSON-API and Fuseki's SPARQL endpoint. The web app component can be relatively trivially re-implemented in a Javascript framework such as Angular or Vue.js and the functionality (i.e. ACME as you see it right now) embedded in a wallet tab. ACME in the wallet, with a configurable whitelist of publishers' addresses plus whatever metadata is retrievable to convey information about the author, title, topic, tags, need, I, go, on. Publishing is ... let's riff on this ... in ACME via a javascript-implemented interface, could even offer in-wallet blogging, hitting “post” submits the content for javascript processing - the content and associated metadata are rendered as RDF, signed and pushed up to the configured ACME SPARQL UPDATE endpoint to be stored in the graph - and the ACME publication API updated. You don't even have to make the inscription, that's done automatically. All you need as a Slimcoin user is an ACME API key and off you go. At some stage archiving and migration functionality can be added but it amounts to little more than hooking up buttons to a few SPARQL queries.

I guess torrent serving could also be made (an optional) part of the package, torrenting does hook into a substantial propagation community, although RDF definitely carries the day when it comes to the extent of the metadata and so can be readily “discovered”.

Which is why ACME will be a self-deploying, as-hands-off-as-I-can-make-it package. I suppose, with a following wind, this might be reasonably mistaken for the raw material for a masternode system an overlay network administered by hoomans instead of an algorithm. It'll have it's pros and cons but it might see some use.

Cheers

Graham

I think that Slimcoin community is larger, and appear to be more responsive, and try to help with development (not to discourage Datacoin community, but still, we are more organized I think), even if most of us don't have skills in programming, also we have @d5000, who is good organizator, and provides some programming too, @cryptovore, with his knowledge, steemit articles, which helped great, and contribution or @dzarmush with his graphics skills and translation to RU, and I'm also trying to make some things, like Slimcoin AIO Client for Windows etc.
We also have now support of at least one exchange, and maybe some more in the future, whereas DTC is non-tradeable as for now, unfortunately.
I looked into the projects, you are contributing now, and I find Datacoin, quite interesting. Would it be a problem to merge our codebases into one ?
Or merge code from Datacoin into Slimcoin (I know it would require hard-fork, and it's a fork of Primecoin, so it has different codebase to our for now)
If we could inherit advantages from 2 of these blockchains, it could really make a difference in crypto, and would be perceived as a real innovation.
I don't know what innovatives have Beecoin, apart from that it was a scam coin, before hard fork to V2, and big circulating supply.

Slimcoin + Datacoin = SlimData ? Yeah it would be great, but would require tremendous amount of work putted into, and if we want to inherit, people from Datacoin community, we would have to swap
their Datacoin's holding into some of the new Slimcoin (SlimData) coins.

[gjhiggins]

Where will the ACME blog posts get published to?  Is it also a reader? 

Might the blog posts go a URL that Slimcoin will be hosting?   

Yes, it's also a reader. The retrieved content is base64-encoded text/html, ready to be base64-decoded and dumped into QtWebView (if you want it in the wallet) or into the html document if it's on an externally-hosted ACME.

The blog posts will go to whichever ACME you want. Maybe you run your own, locally or remotely, maybe you share one with some other people, maybe you took out a subscription to a commercial offering...

Riffing again, ACMEs could differentiate themselves by offering enhanced content presentation or specialising in themed or topic-related content. Or you can have one dedicated to your own content.

There'll probably need to be already-paved cowpaths so that people who opt to gain the advantage of signed graphs are assisted by automatically embedding non-text content as base64-encoded resources because otherwise, the common model of referencing external resources would defeat the purpose of a signed graph - to attest to the integrity of the RDF statements by validating the hash of the serialised graph. With external references, you're basically saying “It was over there, the last time I looked.” Which is a valid statement to make but rather a weak one with little purpose that I can discern. I'm fairly confident that Fuseki's back-end persistence takes advantage of compression and base64-encoded resources suitable for web presentation aren't all that luxurious, so it does seem do-able.

I'm not making any claims for the approach other than it's a means of publishing indexes to signed RDF graphs, with the overall expressive power that brings.


Cheers

Graham

[MercuryProtocol]

Thanks for creating this thread OP.



Is there a contact page if I have any questions or should I just ask them here?

[gjhiggins]

I looked into the projects, you are contributing now, and I find Datacoin, quite interesting. Would it be a problem to merge our codebases into one ?

As I mentioned earlier, I was investigating Datacoin because I was interested in finding out more about how the metadata was handled. With Datacoin, you could run apps straight out of the tx data. Could easily put a lightweight client in there, as binary. Iff you had metadata. You'd have to trust the address of the publisher and that could be conducted in a separate side channel and you could find out the metadata that way. But it's fragmentary, needs to be collated, so I adapted an ACME to check whether it worked in practice - and also get a sense of how much use was being made of that facility (elsewhere this is called “market research”).

As quid pro quo, I'm having a go at contributing an upgrade to a later codebase (aka “gaining experience”). It's what I do. I'm also contributing to Beecoin and Helium, have contributed to BelaCoin, Sprouts, PIVX, the list stretches right back to Feb 2014.

I have been quite specific, I'm a contributor and it would be a mistake to consider me as “the dev” for two reasons, the first is because it runs counter to Teal principles - to have “a dev” is a centralisation influence, the second is because this influence tends to create a central point of (all too human) failure, the very opposite of what was intended. This is a shared resource with shared responsibilities (if it's to sustain itself).

The Slimcoin network is recovering from its Nov 2016 all-time low, the engine's somewhat idiosyncratic-but-not-entirely-unpredictable behaviour is now more widely appreciated and some apparently reliable workarounds exist. By reference to the networks that cryptopia can apparently see, the Slimcoin network is positively glowing with health:



(It is entirely possible that they under-report as much as novaexchange does for Slimcoin nodes https://novaexchange.com/addnodes/SLM/ but even if that is the case, ~40 nodes is still pretty healthy in context.)

There a number of GUI improvements in development, including an incomplete but functioning implementation of watch addresses. The torrenting aspects of web2web publishing proved tedious and torrent metadata is solely concerned with transport and reconstruction of resource fragments, it doesn't even record the mime type of the torrented resource, instead that task is devolved to torrent trackers.

The protocol doesn't really matter, if you're publishing content then if you're not hosting it yourself, someone else is on your behalf. ACME is aimed at allowing club members an alternative to torrenting / coughing up Bitcoin to have content hosted on IPFS. Run your own, share one with others, do as you see fit, there's no constraining cryptographic inheritance here, feel free to be as disorderly and rambunctious as you like.

I have an old blog in XML that I'm planning to render as HTML with base64-encoded resources, I just have to work out a metadata scheme (i.e. set of RDF statements) that I can store in the associated “metadata+content” graph, which I can then use to feed to javascript to get it to programmatically populate the other tabs of the standalone “A different perspective” post, turning it into a micro standalone blog app (with safely-embedded javascript libs + Semantic-UI css framework) with a list of past posts, titles, dates, abstracts, etc. which can be rendered in the wallet as a Qt-driven specialised in-wallet blogging app or the same thing as a component of an ACME instance, wherever hosted. Hey, twitter started out small.

Cheers

Graham

[kimes]

This coin has a shortcoming is more people to dig, dig will lead  to less，

[muf18]

Ok, I now understand (maybe not everything, but I got a sense of what you mean). I didnt mean that dev, must be a centralized position, because there can be a lot of contributing developers as in Bitcoin was before Core team was defined (and thus it meant centralization of developing - I agree with you about that, it's not what we intend to). But I know what you meant.

With Datacoin parts of code, we could make better implementation of web2web, as I see.

@klmes - lead to lower inflation, and thus better value. It's a quite clever system, because it makes to take initiative, when it's low on hashrate and diff, and gradually makes it harder, this mechanism from Peercoin is ok, others (POS shortcomings, and high fees without miner reward, is something to be considered to change)

[gjhiggins]

Ok, I now understand (maybe not everything, but I got a sense of what you mean).

It is a straightforward consequence of my role as first-line partner support. Ngaio is my primary commitment, everything else is secondary.

With Datacoin parts of code, we could make better implementation of web2web, as I see.

That's the leverage I'm looking at.

Cheers

Graham

[gjhiggins]

This coin has a shortcoming is more people to dig, dig will lead  to less，

It is true that can be seen as a shortcoming but it is a deliberate design feature (mentioned the original ANN, see the link in the top-of-thread ANN).

Cheers

Graham

[NoxX]

I got the wallet with blockchain snapshot, took a few hours to sync from there but now I am up to date. I wanted to give mining a shot, and I am wondering how to interpret the difficulty.

POW difficulty is around 0.15 at the moment, can someone tell me roughly what that means in terms of expected coins per hour per 1k H/sec or something similar?

Thanks!

[gavrilo77]

I got the wallet with blockchain snapshot, took a few hours to sync from there but now I am up to date. I wanted to give mining a shot, and I am wondering how to interpret the difficulty.

POW difficulty is around 0.15 at the moment, can someone tell me roughly what that means in terms of expected coins per hour per 1k H/sec or something similar?

Thanks!

Do you use wallet miner? What CPU you have?

[NoxX]

I got the wallet with blockchain snapshot, took a few hours to sync from there but now I am up to date. I wanted to give mining a shot, and I am wondering how to interpret the difficulty.

POW difficulty is around 0.15 at the moment, can someone tell me roughly what that means in terms of expected coins per hour per 1k H/sec or something similar?

Thanks!

Do you use wallet miner? What CPU you have?

Yes, I use the wallet miner. I have different CPUs, but I can check my hashrate with "gethashespersec" in the wallet.

That's why I'm asking for an estimate per 1000 H/sec, so I can calculate the rest myself

[gavrilo77]

I got the wallet with blockchain snapshot, took a few hours to sync from there but now I am up to date. I wanted to give mining a shot, and I am wondering how to interpret the difficulty.

POW difficulty is around 0.15 at the moment, can someone tell me roughly what that means in terms of expected coins per hour per 1k H/sec or something similar?

Thanks!

Do you use wallet miner? What CPU you have?

Yes, I use the wallet miner. I have different CPUs, but I can check my hashrate with "gethashespersec" in the wallet.

That's why I'm asking for an estimate per 1000 H/sec, so I can calculate the rest myself

Wallet miner is slow. Use JonyLatte miner, it is many times faster

[NoxX]

I got the wallet with blockchain snapshot, took a few hours to sync from there but now I am up to date. I wanted to give mining a shot, and I am wondering how to interpret the difficulty.

POW difficulty is around 0.15 at the moment, can someone tell me roughly what that means in terms of expected coins per hour per 1k H/sec or something similar?

Thanks!

Do you use wallet miner? What CPU you have?

Yes, I use the wallet miner. I have different CPUs, but I can check my hashrate with "gethashespersec" in the wallet.

That's why I'm asking for an estimate per 1000 H/sec, so I can calculate the rest myself

Wallet miner is slow. Use JonyLatte miner, it is many times faster

Okay, thanks for the suggestion. I downloaded slimminer and am running that now. It says it is using the Scrypt algorithm, is that correct?

I do get about 10x the hashrate now, assuming everything is working correctly, but my original question still stands, how can I estimate the time to find a block with a given hashrate?

[muf18]

What CPU do you have?
Just do simple math calculation - your hashrate / network hashrate, I think there are about 520 blocks PoW per day (I don't know if number of blocks to approve block is number creating POW blocks per day, even if not it's close number to it like 540-570 I think). And you will know how much you should get.
You should be using DCrypt, because SLM is using Dcrypt as a algo, but if it's running probably with proper libraries, but not optimized. I'll put some guide to mining on yt and now DTube at end of this month I think, because I have a few other things to do, but I'll note it, to make it, with Windows and Linux miners, it will on Slimcoin Community channel.